Question about nmethod flushing

[Coleen Phillimore]

Hi Vladimir,

Thanks for answering my question.  In my case, the sweeper's stack 
traversal doesn't seem to be frequent enough, but if I run a fastdebug 
jvm rather than a debug jvm and helping it along with 
-XX:NMethodSweepFraction=1, I can get my redefined methods finally swept 
so I can deallocate their metadata.

For class redefinition, it seems that I want to make sweeping more 
frequent, but I'm not sure how to do this.  Also, I am testing this with 
a small test case so maybe practically, this isn't really an issue.

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).

Yes, we keep the original class and swap the new methods and their 
constant pool to the original class.  The scratch_class gets the old 
methods and old constant pool attached to it and they're deleted 
together (implicitly).

The irony is that redefine classes also does a stack traversal so we 
know which methods are on the stack but I've spent most of the day 
trying to figure out how to pre-zombie these nmethods but I haven't 
thought of anything that would work better for this test case I wrote.

The sweeper runs during safepoints, doesn't it?

Thanks!
Coleen

>
> 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