Question about nmethod flushing
coleen.phillimore at oracle.com
Wed Aug 13 21:26:09 UTC 2014
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
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?
> 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.
More information about the hotspot-compiler-dev