Hotspot loves PHP.reboot

[Rémi Forax]

On 09/07/2011 01:00 PM, MacGregor, Duncan (GE Energy) wrote:
>
> Could we do pass a method handle into this hypothetical to this 
> hypothetical addDetectingOverflow and allow thus allow the caller to 
> specify what should happen in the overflow case? Or does that still 
> leave too much of a problem regarding actually returning the values?
>

The return value is one problem because what you need to provide
is not the return value of addDetectingOverflow but to the method that 
inlines
(perhaps not directly) addDetectingOverflow.
The other problem is that the VM will have to gather all locals to pass 
them as argument
of the method handle.

It's simpler to jump to a code that will call the interpreter (or 
another compiled code as PyPy does)
hence the use of an exception.

Rémi

> *From:*mlvm-dev-bounces at openjdk.java.net 
> [mailto:mlvm-dev-bounces at openjdk.java.net] *On Behalf Of *John Rose
> *Sent:* 06 September 2011 21:05
> *To:* Da Vinci Machine Project
> *Subject:* Re: Hotspot loves PHP.reboot
>
> On Sep 6, 2011, at 8:51 AM, Charles Oliver Nutter wrote:
>
>
>
> Did we ever figure out if it's possible to trick Hotspot into doing a
> JO instead of the raw bit-level operations? John/Christian/Tom: what
> would it take to get HS to "know" that we're doing an integer
> overflow-after-maths check and do the (faster?) JO?
>
> (1) Write a compelling API for something like 
> Integer.addDetectingOverflow.
>
> (2) Roll it into JDK 8+epsilon.
>
> (3) Do the JIT work.
>
> People have thought on and off about (1) for many years, but with no 
> clear winner.  Exceptions or boxed objects have unpleasant 
> interactions and are hard to use, while smuggling out the 33rd bit 
> some other way (TLS, a long or double, a return-by-reference, a 
> sentinel value) is painful.
>
> (This is a case where tuples would make things simple, but it is not 
> enough to motivate introducing tuples.)
>
> -- John
>
>
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110907/a92fc125/attachment.html