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 "
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,
On Mar 3, 2015, at 3:21 PM, Vladimir Ivanov
wrote:
>
> Ah, I see now.
>
> You suggest to conditionally insert uncommon trap in MHI.profileBoolean when
> a count == 0, right?
>
> Won't we end up with 2 checks if VM can't fold them (e.g. some action in
> between)?
Maybe; that's the weak point
Ah, I see now.
You suggest to conditionally insert uncommon trap in MHI.profileBoolean
when a count == 0, right?
Won't we end up with 2 checks if VM can't fold them (e.g. some action in
between)?
Best regards,
Vladimir Ivanov
On 3/4/15 2:15 AM, Vladimir Ivanov wrote:
Right now, VM doesn't
Right now, VM doesn't care about profiling logic at all. The intrinsic
is used only to inject profile data and all profiling happens in Java
code. Once MHI.profileBoolean is intrinsified (profile is injected),
no profiling actions are performed.
What I'm thinking is that an uncommon trap could r
On Mar 3, 2015, at 8:23 AM, Vladimir Ivanov
wrote:
>
>> Suggestion: Instead of have the intrinsic expand to nothing, have it expand
>> to an uncommon trap (on the slow path), with the uncommon trap doing the
>> profile update operation (as currently coded).
> Right now, VM doesn't care about
Thanks for looking into it Vladimir...I'm standing by to test out anything!
- Charlie
On Tue, Mar 3, 2015 at 10:23 AM, Vladimir Ivanov
wrote:
> John,
>
>> So let's make hindsight work for us: Is there a way (either with or
>> without the split you suggest) to more firmly couple the update to th
John,
So let's make hindsight work for us: Is there a way (either with or without
the split you suggest) to more firmly couple the update to the query?
Separating into two operations might be the cleanest way to go, but I think
it's safer to keep both halves together, as long as the slow pa
On Mar 2, 2015, at 12:00 PM, Vladimir Ivanov
wrote:
>
> Charlie, I found the root cause.
>
> So, the problem is never-taken branches indeed.
> The way how branch profiling for GWT (JDK-8063137 [1]) is performed doesn't
> work well.
>
> I hoped that profile collection and injection actions can
Charlie, I found the root cause.
So, the problem is never-taken branches indeed.
The way how branch profiling for GWT (JDK-8063137 [1]) is performed
doesn't work well.
I hoped that profile collection and injection actions can be merged (
MHI.profileBoolean) into single action, but it's not th
Thanks for the report, Charlie!
The regression is caused by never-taken branch pruning [1].
-Djava.lang.invoke.MethodHandle.PROFILE_GWT=false makes the regression
go away.
My main suspicion is that recompilations caused by pruned branches can
lead to less efficient code. But I have to dig th
I'm finally at home with a working machine so I can follow up on some
VM Summit to-dos.
Vladimir wanted me to test out jdk9 hs-comp, which has all his latest
work on method handles. I wish I could report that performance looks
great, but it doesn't.
Here's timing (in s) of our red/black benchmark
13 matches
Mail list logo
