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-boun...@openjdk.java.net
[mailto:mlvm-dev-boun...@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@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev