RFR(M) 8225019: Update JVMCI
vladimir.kozlov at oracle.com
Fri May 31 20:28:06 UTC 2019
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:
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.
> On 5/31/19 9:38 AM, Vladimir Kozlov wrote:
>> 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.
More information about the hotspot-compiler-dev