RFR: 8219687: G1 asserts nmethod should not be unloaded during parallel code cache unloading

Erik Österlund erik.osterlund at oracle.com
Mon Jun 3 15:39:53 UTC 2019


There is an assert that G1 occasionally hits during parallel code cache 
When oops_do() is called to compute is_unloading(), the nmethod should 
not be unloaded says the assert.

However... imagine the following scenario:

A bunch of parallel GC threads are walking the code cache in parallel, 
unloading dead things.

GC thread 1 finds nmethod A in the code cache iteration. It 
is_unloading(), and hence its method()->method_holder() dependency 
context is found to need cleaning, and cleaning starts. In that 
dependency context, it finds nmethod B, which is asked if it 
is_unloading(). The result of the question is not cached, and calls 
oops_do is used to compute the answer.

GC thread 1 now peempts and wakes up later.

GC thread 2 finds nmethod B in the code cache iteration. It 
is_unloading(), and hence made make_unloaded(), eventually changing the 
state to unloaded.

GC thread 1 now wakes up and runs the assert on nmethod B that it must 
not be unloaded, and we get the stack trace above.

So there is absolutely no harm with calling oops_do on nmethods that 
racingly become unloaded here, and that assertion should just be silenced.




More information about the hotspot-gc-dev mailing list