Lost perf between 8u40 and 9 hs-comp

[Charles Oliver Nutter]

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 "Per" flags did not appear to help performance,
and actually seemd to degrade it almost back to where 8u40 lies.

- Charlie

On Fri, Mar 6, 2015 at 7:06 AM, Vladimir Ivanov
<vladimir.x.ivanov at oracle.com> wrote:
> 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, try -XX:PerBytecodeRecompilationCutoff=-1
> -XX:PerMethodRecompilationCutoff=-1 (to workaround another problem I spotted
> [1]).
>
> On 3/4/15 5:16 AM, John Rose wrote:
>>
>> On Mar 3, 2015, at 3:21 PM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
>> 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 of the idea.  The VM *does* fold many
>> dominating ifs, as you know.
>>
>> But, if the profileBoolean really traps on one branch, then it can return
>> a *constant* value, can't it?
>>
>> After that, the cmps and ifs will fold up.
>
> Brilliant idea! I think JIT can find that out itself, but additional help
> always useful.
>
> The real weak point IMO is that we need to keep MHI.profileBoolean intrinsic
> and never-taken branch pruning logic during parsing (in parse2.cpp) to keep
> in sync. Otherwise, if VM starts to prune rarely taken branches at some
> point, we can end up in the same situation.
>
> Best regards,
> Vladimir Ivanov
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8074551
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev