Deoptimization of frozen frames

[Ron Pressler]

Just note that chunks are the main mechanism, and disabling them is mostly exposed for now for
diagnostic purposes. Deoptimisation will *not* be done lazily on thawing, as it is done when chunks
are disabled, and there is no concept of deoptimising frozen frames. In fact, the entire concept of
deoptimising a *frame* might be gone altogether.

Just to give a sense of what we’re thinking, in broad strokes: rather than deoptimise *frames*, that, in the
Loom world, may live on the heap in “ordinary” objects (in the sense that they’re not specially registered by
the VM), just mark nmethods in a way that will be trapped when they are returned to. Whether we end up
doing this or something else is TBD.

— Ron


On 17 November 2020 at 18:19:51, Reingruber, Richard (richard.reingruber at sap.com) wrote:

> 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