Question about nmethod flushing

[albert noll]

On 13.08.2014 23:26, Coleen Phillimore wrote:
>
> 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?
Only marking nmethods as 'seen_on_stack' is done at safepoints.

Best,
Albert

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