Re: [ljc] JVM support for unsigned arithmetic

From: Richard G.
Sent on: Tuesday, August 28, 2012 11:45 PM
Hello Mike,

>> And no... no JIT magic/optimization can be applied.
> For the overflow case, I thought it would be fairly straight forward
> for the JVM to implement an intrinsic to provide machine specific
> assembly.  Is there are reason why this technique can be applied?
>
> Mike.

I found this article below, which explains how overflows could be detected.
The article explains why it's not going to perform well. :(
http://www.drdobb...­

Could you please clarify what an "intrinsic" is and how it could speed 
up execution via machine specific assembly?

Thanks

Richard Gomes
mobile : [masked]
email  : [address removed]
twitter: frgomes
YM     : rgomes1997
gtalk  : rgomes1997
--------------------­--------------------­--------------------­-------
Skype: dial skype2ippi           then dial[masked] when prompted.
GTalk: dial [address removed]  then dial[masked] when prompted.
SIP  : dial [address removed]
iNUM : [masked]http://www.inum.n...­

On 28/08/12 20:01, Richard Gomes wrote:
> 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]
>>
>>
>
>
>
>
> --
> 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 Gomes ([address removed]) from LJC - London Java Community.
> To learn more about Richard Gomes, 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 12/13 Jun 14

  • SkillsMatter

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

  • Packt Publishing

    A publishing company specializing on specific technologies and solutions

  • 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