Question about nmethod flushing

Coleen Phillimore coleen.phillimore at
Thu Aug 14 14:52:02 UTC 2014

So I'm still worried about this.  In 
Universe::flush_evol_dependents_on() I think it's probably fine to make 
the redefined (old) methods into zombies and not just not-entrant.  But 
this doesn't make them swept any sooner.  With NmethodSweepFraction=1, 
they are finally swept after 71 GCs and without this option they are 
never swept.  Is there any way to programmatically tell the sweeper to 
run to completion just after a class redefinition?   Sort of like 
telling GC to run a full GC?


On 8/12/14, 7:58 PM, Vladimir Kozlov wrote:
> nmethods are alive when there are corresponding stack frames on java 
> execution stacks. We can't make them zombie until we 100% sure they 
> are not used.
> Is it possible that we are reaching a nmethod even if it is not 
> present on call stack? The main method for marking is 
> nmethod::mark_as_seen_on_stack() and it is called from a lot of 
> places. May be with class redefinition there is some kind of a loop - 
> we can't unload metadata <-> nmethod is reachable.
> Also I thought that we keep the original class when do redefinition 
> (at least Serguei Spitsyn told me that, I think).
> Thanks,
> Vladimir
> On 8/12/14 3:12 PM, Coleen Phillimore wrote:
>> I have a question about nmethod flushing wrt to RedefineClasses (no, no,
>> no, please keep reading!)
>> When we redefine a class, there is code to deoptimize the methods, and
>> make them non-entrant.   Non-entrant methods are still considered alive,
>> so for class redefinition we walk the code cache so that we don't delete
>> the metadata for any methods while some nmethod is still referring to
>> it.   Eventually the sweeper will come along and mark the methods as
>> zombies so we don't have to deal with them anymore, but for class
>> redefinition, can we force methods to go to zombie's earlier? Or make
>> the sweeper more aggressive after a class redefinition?
>> This code cache walking isn't that expensive, but we keep around a lot
>> of metadata as a result that could be more eagerly deleted.
>> Thanks,
>> Coleen

More information about the hotspot-compiler-dev mailing list