[9,8u60] RFR (S): 8074551: GWT can be marked non-compilable due to deopt count pollution

[Vladimir Ivanov]

Thanks, Vladimir.

Best regards,
Vladimir Ivanov

On 6/10/15 8:04 PM, Vladimir Kozlov wrote:
> Looks good to me.
>
> Thanks,
> Vladimir K.
>
> On 6/10/15 5:34 AM, Vladimir Ivanov wrote:
>> http://cr.openjdk.java.net/~vlivanov/8074551/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8074551
>>
>> JDK-8063137 added profiling machinery for GWT combinator.
>> In order to avoid trap count pollution, trap counts are simply ignored
>> during JIT compilation for methods w/ injected profile.
>>
>> Unfortunately, it not enough to completely eliminate trap count
>> pollution problem. As the regression test case demonstrates, VM marks
>> heavily shared method as non-compilable when too many traps happen
>> there. It causes severe performance regression since the method is
>> neither compiled nor inlineable anymore.
>>
>> With the fix, VM doesn't update trap counts in methods with injected
>> profile when trap reason is either intrinsic or unreached. These are 2
>> kinds of uncommon traps VM issues based on injected profile.
>>
>> I experimented with completely ignoring trap count updates for methods
>> with injected profile, but it causes noticeable regression on a couple
>> of Octane subbenchmarks [2].
>>
>> I reverted injected profile detection logic and reintroduced an explicit
>> marker for methods which inject profile (@InjectedProfile). All GWTs are
>> marked with it during bytecode translation.
>>
>> Testing: jdk/test/java/lang/invoke, hotspot/test/compiler/jsr292,
>> nashorn, octane (no perf regression)
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8063137
>> [2] FTR Richards (340ms->370us) & Regexp(100ms->135ms)