Lost perf between 8u40 and 9 hs-comp

[Vladimir Ivanov]

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 performance regressions 
caused by heavy bytecode sharing. So, it would be useful to compare 
fully customized (pre-8u40) vs heavily shared (8u40/9) implementations.

> 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.
That would be great!

> FWIW, the additional "Per" flags did not appear to help performance,
> and actually seemd to degrade it almost back to where 8u40 lies.
It seems the hammer is too large then :-) Ignore them unless you see 
severe perf regression (that's usually how JDK-8074551 manifests 
itself). I'll let you know once I have a fix.

Best regards,
Vladimir Ivanov

>
> - 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
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>