RFR: JDK-8132849: Increased stop time in cleanup phase because of single-threaded walk of thread stacks in NMethodSweeper::mark_active_nmethods()

Roman Kennke rkennke at redhat.com
Mon Sep 24 13:21:01 UTC 2018

> So my suggestion for now is:
> Do nmethod marking in VM operation/handshake operation.
> Do hotness counter updating when UseCodeAging in safepoint cleanup.

Ok, this change should do that:

Note that nmethod-marking still resets hotness counters.

Good now for pushing?


> And now you might be wondering if it really makes sense to walk all
> stacks in the system every safepoint, to provide some heuristic about
> whether nmethods are inactive or not. Arguably not. I have an idea about
> a much better way of doing this. I will get back to you in a few days
> about that.
> Hope this helps.
> Thanks,
> /Erik
> On 2018-09-24 11:36, Roman Kennke wrote:
>>> Is there a use of doing nmethod marking more frequently than what is
>>> forced in do_stack_scanning() ?
>> As far as I can tell, it is sufficient to mark nmethods right before
>> sweeping. It might even be counter-productive to do more marking passes:
>> it would result in more non-entrant nmethods marked as 'seen on stack'
>> even if they are no longer on stack.
>> I am not 100% sure about the hotness counter though. From what I see,
>> it's only used for sweeper too, and it really looks like resetting the
>> counter on nmethod-walk is enough. But I'd like confirmation from
>> somebody who knows better than I do. If it's really good enough, we may
>> remove the nmethod stuff completely from SP cleanup, and also remove the
>> hotness-counter-closure, and always piggy-back the stuff on nmethod
>> walking, either in its own VM_Op, or in its handshake.
>> On the other hand, why is hotness counting and nmethod marking split out
>> in sp-cleanup in the first place then?
>> Roman

More information about the hotspot-runtime-dev mailing list