Implementation of transfers out of closures
John.Rose at Sun.COM
Fri Jul 18 11:53:58 PDT 2008
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
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-
Please see this thread for related discussions:
Also, Hotspot 7 support a disassembler plugin which can guide code
shape studies. See:
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
> ---------- 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:
> 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
>>> The structure of the generated code should take advantage of
>>> existing hotspot optimizations and enable new ones.
More information about the closures-dev