Question about nmethod flushing
Coleen Phillimore
coleen.phillimore at oracle.com
Thu Aug 14 14:52:02 UTC 2014
Hi,
So I'm still worried about this. In
Universe::flush_evol_dependents_on() I think it's probably fine to make
the redefined (old) methods into zombies and not just not-entrant. But
this doesn't make them swept any sooner. With NmethodSweepFraction=1,
they are finally swept after 71 GCs and without this option they are
never swept. Is there any way to programmatically tell the sweeper to
run to completion just after a class redefinition? Sort of like
telling GC to run a full GC?
Thanks,
Coleen
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).
>
> 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
More information about the hotspot-compiler-dev
mailing list