Implementation of transfers out of closures

[John Rose]

On Jul 18, 2008, at 8:28 AM, Neal Gafter wrote:
> Here is some interesting fodder for possible hotspot optimizations.
> These measure the performance of the initial implementation of
> nonlocal returns.  Mark didn't warm up the VM in his tests, but I
> found that didn't make much difference.

Yes, that's interesting.  Thanks for sending Mark's code examples.   
Your design constraints look just right to me.

The advantage from hand-inlining points to a possible use case for  
inlining advice.  But more likely, the JVM will want to recognize the  
idiom (in some generic, robust way) and optimize it well.  We already  
have an inlining heuristic that looks for throwing activity, more is  
probably needed.

In the example code, the dead field is superfluous.  The code should  
just set frame$.thread to null.  One variable is always better than  
two, as far as the JIT is concerned.

It is often better to put the throw early in the code, as soon as you  
know there is going to be a throw, rather than make a method call  
which never returns and throw from inside.  Less for the compiler and  
runtime to unwrap.  Therefore, you might want to consider making the  
throwiness of Jump.transfer public:  Have transfer return a RuntimeEx  
which the caller must then throw.  It's no loss of generality:  The  
transfer method does not actually need to return on all implementations.

(I like the idea of having UnmatchedNonlocalTransfer confess its  
target thread, and offer to restart the jump.  Gives unexpected hope  
for interoperability to thread-splitting algorithms, like work- 
stealing evaluators.)

Please see this thread for related discussions:
   http://mail.openjdk.java.net/pipermail/mlvm-dev/2008-May/000114.html
   http://mail.openjdk.java.net/pipermail/mlvm-dev/2008-June/000116.html

Also, Hotspot 7 support a disassembler plugin which can guide code  
shape studies.  See:
   http://wikis.sun.com/display/HotSpotInternals/PrintAssembly
   http://wikis.sun.com/display/HotSpotInternals/MicroBenchmarks

The code sample for this blog entry is still worth looking at for  
ideas, such as an assertion-like switch which turns on backtraces for  
debugging:
   http://blogs.sun.com/jrose/entry/longjumps_considered_inexpensive

Best wishes,
-- John

> ---------- Forwarded message ----------
> From: Mark Mahieu <mark at twistedbanana.demon.co.uk>
> Date: Mon, Jul 14, 2008 at 12:33 PM
> Subject: Re: Implementation of transfers out of closures
> To: Neal Gafter <neal at gafter.com>
> Cc: closures-dev at openjdk.java.net
>
>
> Here are versions which pass the code containing the Jump as a closure
> - not directly comparable to the NormalReturn class:
>
> http://slm888.com/snippets/JumpReturnClosure.java
> http://slm888.com/snippets/InlinedJumpReturnClosure.java
>
> The inlined version seems to complete in about 50% of the time on the
> non-inlined version.
>
>
> On 14 Jul 2008, at 20:09, Mark Mahieu wrote:
>
>> On 14 Jul 2008, at 01:11, Neal Gafter wrote:
>>>
>>> I have the following design constraints:
>>> The "normal" case should be relatively fast. Specifically, there  
>>> should be no capturing of a stack trace when the transfer is  
>>> successful.
>>> The structure of the generated code should take advantage of  
>>> existing hotspot optimizations and enable new ones.
>> ...