Deoptimization of frozen frames

[Reingruber, Richard]

  > This is a known issue when continuation chunks are used (try with -XX:-UseContinuationChunks).

Yes, it is working indeed.

Thanks, Richard.

From: Ron Pressler <ron.pressler at oracle.com> 
Sent: Dienstag, 17. November 2020 19:01
To: Reingruber, Richard <richard.reingruber at sap.com>; loom-dev at openjdk.java.net
Subject: Re: Deoptimization of frozen frames

Thank you.
This is a known issue when continuation chunks are used (try with -XX:-UseContinuationChunks).
We will likely change the deoptimisation mechanism to address this.

— Ron


On 17 November 2020 at 17:30:15, Reingruber, Richard (mailto:richard.reingruber at sap.com) wrote:
Hi, 

I've been trying to learn a little bit about the hotspot side of loom recently. 

For instance I wanted to know, how frozen compiled frames are deoptimized 
e.g. because a class is loaded that overrides a virtual method. 

I wrote a test for this [1] and learned that frozen frames are lazily 
deoptimized when being thawed. 

But the test behaves unexpectedly when using many (>10000) virtual threads. It 
seems that sometimes the deoptimization is missed and the invalid compiled code 
is executed (see output at [2]). In fact I verified this by setting a breakpoint 
in the compiled code for dontinline_testMethod() right after the call to 
dontinline_recurseAndWaitForNewValueGetter1 and found that this breakpoint() was 
hit after the nmethod was made not entrant. 

Further observations 

(O1) The test fails when using virtual threads. It seems to be quite random 
though when the failures occur. 
./images/jdk/bin/java -XX:-TieredCompilation -XX:CICompilerCount=1 -Xbatch -XX:CompileCommand=dontinline,*::dontinline_* loom_tests/TestDeoptAfterClassLoading.java vt 

(O2) The test always succeeds when using native os threads. 
(Beware: many threads are started!) 
./images/jdk/bin/java -XX:-TieredCompilation -XX:CICompilerCount=1 -Xbatch -XX:CompileCommand=dontinline,*::dontinline_* loom_tests/TestDeoptAfterClassLoading.java nt 

(O3) Control returns into not entrant nmethod dontinline_testMethod() and hits a gdb breakpoint. 

I hope there's no bug in the test. Especially because of O3 I'd think there is 
an issue with frame deoptimization. 

I'd be interrested in your thoughts on this test. 

Thanks, Richard. 

[1] http://cr.openjdk.java.net/~rrich/loom_tests/TestDeoptAfterClassLoading.java 
[2] http://cr.openjdk.java.net/~rrich/loom_tests/TestDeoptAfterClassLoading_vt.log