RFR: 8213755: Let nmethods be is_unloading() outside of safepoints

Erik Österlund erik.osterlund at oracle.com
Mon Nov 12 22:46:28 UTC 2018


..put in bug number in subject to make mail filters happy.

/Erik

On 2018-11-12 23:44, Erik Österlund wrote:
> Hi,
> 
> All current GCs perform code cache unloading in safepoints. Therefore, 
> nmethods that are alive but is_unloading() are never observed outside of 
> safepoints. With concurrent class unloading, nmethods that are alive but 
> is_unloading() will become observable outside of safepoints. This must 
> be handled appropriately.
> 
> In this patch I changed the nmethod/compiled method iterators to accept 
> parameters describing whether they should filter out not is_alive() or 
> is_unloading() methods. Since there is no obvious default (all 
> combinations are used depending on call site), you have to explicitly 
> set what iteration mode you want.
> 
> Other than that, I make sure that the sweeper stays away from 
> is_unloading() nmethods that are not yet is_unloaded(). To make the 
> interactions between the sweeper and concurrent GC threads safe, I had 
> to move down the store that sets the state to unloaded, and use a 
> release_store there, to make sure no accesses float below it at 
> compile-time. Once that store is observed, nmethods may be deleted.
> 
> In the IC miss handler, I also need to lazily clean stale IC caches due 
> to calling is_unloading nmethods using nmethod entry barriers.
> 
> Webrev:
> http://cr.openjdk.java.net/~eosterlund/8213755/webrev.00/
> 
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8213755
> 
> Thanks,
> /Erik


More information about the hotspot-dev mailing list