addressalign-toparrow-leftarrow-rightbackbellblockcalendarcameraccwcheckchevron-downchevron-leftchevron-rightchevron-small-downchevron-small-leftchevron-small-rightchevron-small-upchevron-upcircle-with-checkcircle-with-crosscircle-with-pluscontroller-playcrossdots-three-verticaleditemptyheartexporteye-with-lineeyefacebookfolderfullheartglobegmailgooglegroupshelp-with-circleimageimagesinstagramFill 1light-bulblinklocation-pinm-swarmSearchmailmessagesminusmoremuplabelShape 3 + Rectangle 1ShapeoutlookpersonJoin Group on CardStartprice-ribbonprintShapeShapeShapeShapeImported LayersImported LayersImported Layersshieldstartickettrashtriangle-downtriangle-uptwitteruserwarningyahoo

Re: [ljc] JVM support for unsigned arithmetic

From: user 8.
Sent on: Friday, August 24, 2012 4:15 PM
Hi Richard,

Your assembly is not that rusty. You pointed out the basic idea.

To me looks natural to think that the JVM knows the native hardware it 
is running on top of.
So, it would be trivial to have the JVM generating whatever opcodes it 
makes sense for such hardware platform, handle interrupts and all sort 
of low level stuff. When I saw how overflows was implemented... it looks 
like no one is willing to touch the low level stuff in the JVM, but 
implement it "the easy way" in the JDK instead. Despite it's an "easy 
way", it's definitely a sluggish way: it simply does not make sense 
replacing a single opcode (in the native hardware) by several opcodes. 
And no... no JIT magic/optimization can be applied.

Cheers



On 22/08/12 10:54, Richard Warburton wrote:
>> I'm concerned with the way numeric computation is being overlooked in the platform. Handling of overflows is another concern I have: the solution being pushed onto JDK8 does not look appropriate to me, because detection of overflow is not responsibility of the library (namely: JDK), but the processor (namely: JVM). Well... this is another subject, but reinforces my concerns about how numeric computation was never addressed properly by the platform and, unfortunately, is still being overlooked.
> Part of the introduction of those methods was motivated by JSR-310,
> which fails-fast when an overflow happens.  It was thus sensible to
> introduce these utility methods as a general thing, rather than just
> within the Threeten implementation.
>
> Its slightly unclear what will be implemented for Java 8, since
> there's a lot of things to be implemented before release and I'd doubt
> this is high priority, but there was some talk about architecture
> specific JIT optimizations.  I would guess that on x86 that means an
> overflow interrupt handler gets registered and the method call
> replaced by an "ADD" and then an "INTO" to generate the interrupt, but
> my assembly is rusty.
>
> regards,
>
>    Richard
>
>
>
>
> --
> Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
> http://www.meetup...­
> This message was sent by Richard Warburton ([address removed]) from LJC - London Java Community.
> To learn more about Richard Warburton, visit his/her member profile: http://www.meetup...­
> Set my mailing list to email me
>
> As they are sent
> http://www.meetup...­
>
> In one daily email
> http://www.meetup...­
>
> Don't send me mailing list messages
> http://www.meetup...­
> Meetup, PO Box 4668 #37895 New York, New York[masked] | [address removed]
>
>

Our Sponsors

  • Our Blog

    Read the latest news from the LJC

  • RecWorks Ltd

    Fixing Tech Recruitment using the Power of Community

  • jClarity

    Java/JVM Performance Analysis Tools & mentoring for Java related matters

  • LJC Aggrity

    Our LJC Aggrity site contains blog posts from our members

  • LJC Book Club

    Our Book club with book reviews from our members

  • Devoxx UK

    Java Community Conference in collaboration with the LJC, 8-10th June 16

  • SkillsMatter

    "Host, help organise, promote, film many of our meetings."

  • IBM

    Build Enterprise-grade apps at start-up speed.

  • New Relic

    New Relic makes sense of billions of metrics a day in real time.

  • Hazelcast

    Hazelcast is the leader in operating in-memory computing.

  • Java.Net

    We are an official Java User Group recognised by Oracle's JUG program

  • JRebel

    Free 3 month J-Rebel license.

  • O'Reilly

    40% discount on printed books and 50% on e-books.

People in this
Meetup are also in:

Sign up

Meetup members, Log in

By clicking "Sign up" or "Sign up using Facebook", you confirm that you accept our Terms of Service & Privacy Policy