On Mar 4, 2015, at 2:47 PM, Charles Oliver Nutter wrote:
>
> Busy week, finally circling back to this thread...
>
> On Wed, Feb 25, 2015 at 8:29 PM, John Rose wrote:
>>> * A loop handle :-)
>>>
>>> Given a body and a test, run the body until the test is false. I'm
>>> guessing there's a good r
On Mar 6, 2015, at 5:30 AM, Vladimir Ivanov
wrote:
>
>>> * try/finally as a core atom of MethodHandles API.
>>>
>>> Libraries like invokebinder provide a shortcut API To generating the
>>> large tree of handles needed for try/finally, but the JVM may not be
>>> able to optimize that tree as wel
That was quick! Thanks a lot for the feedback.
Ok, now we're cracking! Performance has definitely returned, and
actually improved 15-20% beyond my current copy of 8u40. Bravo!
I'd suggest to add pre-8u40 jdk into consideration as well. As part of
LF sharing effort, I spent much time healing per
Ok, now we're cracking! Performance has definitely returned, and
actually improved 15-20% beyond my current copy of 8u40. Bravo!
I will try testing several other benchmarks, and perhaps set up a
machine to do the big perf regression suite the JRuby+Truffle guys
made for us.
FWIW, the additional "
>From Valdimir
We don't want to make Unsafe.defineAnonymousClass() part of public API,
but consider moving forward on that front providing lightweight code
loading machinery.
While I used defineAnno for awhile currently I just use defineClass in my
own class loader.
My only concern is that pe
* try/finally as a core atom of MethodHandles API.
Libraries like invokebinder provide a shortcut API To generating the
large tree of handles needed for try/finally, but the JVM may not be
able to optimize that tree as well as a purpose-built adapter.
I agree there. We should put this in.
In other words, what we discussed was how do we see lightweight bytecode
loading functionality in java.lang.invoke API.
We don't want to make Unsafe.defineAnonymousClass() part of public API,
but consider moving forward on that front providing lightweight code
loading machinery.
Best regards
John,
You are absolutely right. I should've spent more time exploring the code
than writing emails :-)
Here's the fix:
http://cr.openjdk.java.net/~vlivanov/8074548/webrev.00/
Charlie, I'd love to hear your feedback on it. It fixes the regression
on bench_red_black.rb for me.
Also, please,
