[13] RFR(M) 8225019: Update JVMCI

[Vladimir Kozlov]

Thank you, Dean

There is JDK-8173112.

Yes, I think it may help C2. Tom explained that changes fixed issue with Graal unable to OSR compile a method due to 
low/0 invocation count and stuck in tier3.

Igor pointed in comment that JDK-8173112 is about tier3 code speed and not about how fast we replace it with other 
tiers. The underlining problem is not fixed yet - how to force profile counters only grow and not reset back to 0:

http://hg.openjdk.java.net/jdk/jdk/file/ae908641e726/src/hotspot/share/c1/c1_LIRGenerator.cpp#l3280

Thanks,
Vladimir

On 5/31/19 1:15 PM, dean.long at oracle.com wrote:
> Looks good.  Was there a JDK bug for this fix:
> 
>    GR-15425 Ensure not compilable OSR at level 4 falls back to level 1.
> 
> It looks like it could apply to C1/C2 too and not just JVMCI.
> 
> dl
> 
> On 5/31/19 9:38 AM, Vladimir Kozlov wrote:
>> http://cr.openjdk.java.net/~kvn/8225019/webrev.02/
>> https://bugs.openjdk.java.net/browse/JDK-8225019
>>
>> Sync latest changes from graal-jvmci-8.
>>
>> Several compiler/jvmci tests failed because now VM will exit if JVMCI Compiler specified incorrectly 
>> (-Djvmci.Compiler=null) when UseJVMCICompiler is ON.
>>
>> The exit was added by [GR-15954] "Fail gracefully if JVMCI compiler initialization fails".
>> This is correct behavior. Tests were fixed by replacing -Djvmci.Compiler=null with -XX:-UseJVMCICompiler.
>> Note, I reproduced the same failures back to JDK 10 when we enabled Graal as JIT. Tests passed before because Graal 
>> initialization failures were ignored.
>>
>> Found an other test compiler/uncommontrap/DeoptReallocFailure.java which use small Java heap -Xmx100m to trigger 
>> allocation failures. We should not run it with Java Graal - I put it in ProblemList-graal.txt with JDK-8196611 
>> umbrella bug.
>>
>> Tested with tier1-3.
>>
>> Thanks,
>> Vladimir
>