Question about nmethod flushing

[Vladimir Kozlov]

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