Lost perf between 8u40 and 9 hs-comp

[Vladimir Ivanov]

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