JDK-8217758 : [Graal] Graal should retain local variables if jvmti can_pop_frame/can_access_local_variables capability is set
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 12,13
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-01-25
  • Updated: 2019-08-15
  • Resolved: 2019-03-29
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 13
13Fixed
Related Reports
Blocks :  
Relates :  
Description
This tests fails for me in jdk12 and jdk13 if I run with -XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler -Xcomp:

----------System.out:(11/2320)----------
run [ExecDriver, --java, -XX:-Inline, -XX:CompileThreshold=900, -Xbatch, -XX:-TieredCompilation, -agentlib:hs203t004=pathToNewByteCode=./bin -waittime=5 package=nsk samples=100 mode=compiled, nsk.jvmti.scenarios.hotswap.HS203.hs203t004.hs203t004]
exec [/scratch/mesos/jib-master/install/2019-01-25-0228474.alexey.menkov.jdk12/macosx-x64-debug.jdk/jdk-12/fastdebug/bin/java, -XX:MaxRAMPercentage=6, -Xcomp, -XX:+UnlockExperimentalVMOptions, -XX:+EnableJVMCI, -XX:+TieredCompilation, -XX:+UseJVMCICompiler, -Djvmci.Compiler=graal, -cp, /scratch/mesos/slaves/07fc96ef-bf4d-487f-b22f-a84e49f5f44a-S47657/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/15b2dea8-e6cd-43f7-9eba-c7b44b65cdb6/runs/1e963de3-2a5b-4904-8831-afef2e231f53/testOutput/test-support/jtreg_open_test_hotspot_jtreg_vmTestbase_nsk_jvmti/classes/2/vmTestbase/nsk/jvmti/scenarios/hotswap/HS203/hs203t004/hs203t004.d:/scratch/mesos/slaves/07fc96ef-bf4d-487f-b22f-a84e49f5f44a-S47657/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/15b2dea8-e6cd-43f7-9eba-c7b44b65cdb6/runs/1e963de3-2a5b-4904-8831-afef2e231f53/testOutput/test-support/jtreg_open_test_hotspot_jtreg_vmTestbase_nsk_jvmti/classes/2/vmTestbase:/scratch/mesos/slaves/07fc96ef-bf4d-487f-b22f-a84e49f5f44a-S47657/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/15b2dea8-e6cd-43f7-9eba-c7b44b65cdb6/runs/1e963de3-2a5b-4904-8831-afef2e231f53/testOutput/test-support/jtreg_open_test_hotspot_jtreg_vmTestbase_nsk_jvmti/classes/2/test/lib, -Djava.library.path=/scratch/mesos/jib-master/install/2019-01-25-0228474.alexey.menkov.jdk12/macosx-x64-debug.test/hotspot/jtreg/native, -XX:-Inline, -XX:CompileThreshold=900, -Xbatch, -XX:-TieredCompilation, -agentlib:hs203t004=pathToNewByteCode=./bin -waittime=5 package=nsk samples=100 mode=compiled, nsk.jvmti.scenarios.hotswap.HS203.hs203t004.hs203t004]
 MyThread :: MyThread().
 MyThread.doThisFunction().
# info :: File = ./bin/newclass00/nsk/jvmti/scenarios/hotswap/HS203/hs203t004/MyThread.class 
#  info **Agent:: opening file ./bin/newclass00/nsk/jvmti/scenarios/hotswap/HS203/hs203t004/MyThread.class 
# info file size= 1018
 File red completely 
Exception in thread "Thread-0" java.lang.NullPointerException
	at nsk.jvmti.scenarios.hotswap.HS203.hs203t004.MyThread.run(Unknown Source)
 Thread state = 1100
----------System.err:(18/6025)----------
java.lang.AssertionError: [/scratch/mesos/jib-master/install/2019-01-25-0228474.alexey.menkov.jdk12/macosx-x64-debug.jdk/jdk-12/fastdebug/bin/java, -XX:MaxRAMPercentage=6, -Xcomp, -XX:+UnlockExperimentalVMOptions, -XX:+EnableJVMCI, -XX:+TieredCompilation, -XX:+UseJVMCICompiler, -Djvmci.Compiler=graal, -cp, /scratch/mesos/slaves/07fc96ef-bf4d-487f-b22f-a84e49f5f44a-S47657/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/15b2dea8-e6cd-43f7-9eba-c7b44b65cdb6/runs/1e963de3-2a5b-4904-8831-afef2e231f53/testOutput/test-support/jtreg_open_test_hotspot_jtreg_vmTestbase_nsk_jvmti/classes/2/vmTestbase/nsk/jvmti/scenarios/hotswap/HS203/hs203t004/hs203t004.d:/scratch/mesos/slaves/07fc96ef-bf4d-487f-b22f-a84e49f5f44a-S47657/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/15b2dea8-e6cd-43f7-9eba-c7b44b65cdb6/runs/1e963de3-2a5b-4904-8831-afef2e231f53/testOutput/test-support/jtreg_open_test_hotspot_jtreg_vmTestbase_nsk_jvmti/classes/2/vmTestbase:/scratch/mesos/slaves/07fc96ef-bf4d-487f-b22f-a84e49f5f44a-S47657/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/15b2dea8-e6cd-43f7-9eba-c7b44b65cdb6/runs/1e963de3-2a5b-4904-8831-afef2e231f53/testOutput/test-support/jtreg_open_test_hotspot_jtreg_vmTestbase_nsk_jvmti/classes/2/test/lib, -Djava.library.path=/scratch/mesos/jib-master/install/2019-01-25-0228474.alexey.menkov.jdk12/macosx-x64-debug.test/hotspot/jtreg/native, -XX:-Inline, -XX:CompileThreshold=900, -Xbatch, -XX:-TieredCompilation, -agentlib:hs203t004=pathToNewByteCode=./bin -waittime=5 package=nsk samples=100 mode=compiled, nsk.jvmti.scenarios.hotswap.HS203.hs203t004.hs203t004] exit code is 97
	at ExecDriver.main(ExecDriver.java:139)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:567)
	at PropertyResolvingWrapper.main(PropertyResolvingWrapper.java:104)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:567)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
	at java.base/java.lang.Thread.run(Thread.java:835)
Comments
fixed in Graal Update: http://hg.openjdk.java.net/jdk/jdk/rev/37648a9c4a6a
29-03-2019

http://cr.openjdk.java.net/~jcm/8217758/webrev.00/
07-03-2019

Graal: Use c2v/unsafe to get jvmti capability, and use it for changing compiler option at compileMethod entry.
07-03-2019

as it is pain to fix tests each time we encounter the issue. we have decided to go with compiler fix. 1) to make graal to work like c1/c2 2) to invalidate/disable aot code when feature is enabled.
27-02-2019

as suggested in IM, will use test case fix, as compiler fix wouldn't work for aot/ previous versions(explicit invalidating all previous version of method required)
25-02-2019

Jamsheed, after taking another look at this, I don't think this is related to JDK-8195635. It looks more like JDK-8210257, where Graal has determined the local for "this" is no longer live. Then when we PopFrame and reexecute, we have a null receiver object because of the dead local in the callee. -J-Dgraal.OptClearNonLiveLocals=false is a workaround, but not ideal. Adding Reference.reachabilityFence(this) to the end of the problem method also works.
25-02-2019

Thank you Dean. let me double check and confirm. and as discussed in IM. will try these 1) making -J-Dgraal.OptClearNonLiveLocals=false internally if Jvmti popframe is enabled ? 2) make the local live throughout the callee (test case fix).
25-02-2019

the receiver is null after popframe and reexecute. causing null pointer exception. checking how receiver got null.
25-02-2019

ok, let me try that, Thank you Dean.
22-02-2019

This test uses PopFrame, so it won't work because of JDK-8218025. This is most likely a duplicate of JDK-8195635. If you want to reproduce it to confirm, you'll need to backout JDK-8218025 first.
22-02-2019

test doesn't crash with recent builds(very intermittent), getting old build for a reproducer.
22-02-2019

[~dlong] so shall i close as duplicate?
22-02-2019

ILW = Test fails due to NPE, single test with Graal as JIT (experimental), disable Graal = MLH = P4
29-01-2019