Question about nmethod flushing
albert.noll at oracle.com
Thu Aug 14 02:25:56 UTC 2014
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.
>> On 8/12/14 3:12 PM, Coleen Phillimore wrote:
>>> I have a question about nmethod flushing wrt to RedefineClasses (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
>>> so for class redefinition we walk the code cache so that we don't
>>> 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.
More information about the hotspot-compiler-dev