RFR: 8209189: Make CompiledMethod::do_unloading more concurrent
Erik Österlund
erik.osterlund at oracle.com
Fri Oct 19 14:22:50 UTC 2018
Hi,
Today the nmethods are unloaded either serially or in parallel due to GC
(and e.g. class unloading). With ZGC concurrent class unloading, a
concurrent fashion is required. Rather than inventing yet a third way of
unloading nmethods due to class unloading, it would be ideal if there
could be one unified way of doing it that makes everyone happy.
To solve this problem in a more general way, a new member function on
CompiledMethod is added: is_unloading(). It returns whether a
CompiledMethod has broken oops. In order to not have to iterate over all
the oops every time this question is asked, it caches the result, so it
needs to be computed only once per "epoch". Every time a CodeCache
unloading is triggered by the GC, a new epoch is started, which forces
re-computation of whether the CompiledMethod is_unloading() the first
time it is called.
So by having is_unloading() be lazily evaluated, it is now possible to
build a do_unloading() method on nmethod that simply makes the nmethod
unloaded if it is_unloading(), and otherwise cleans the various caches.
Cleaning e.g. the inline caches of said nmethod, uses the same
is_unloading() method on its targets to figure out if the IC cache
should be cleaned or not. Again, the epoched caching mechanism makes
sure we don't recompute this value.
The new do_unloading() method may be called in both serial, parallel and
concurrent contexts. So I removed the parallel variation of this that we
had before, that unnecessarily postponed the unloading due to not having
computed whether the nmethod should be unloaded or not. Since that is
now computed on-demand lazily, there is no longer a need for postponing
this, nor to have two phases for parallel nmethod unloading.
While there is more work involved in making concurrent nmethod unloading
work, this is a good cleanup towards that goal.
Bug ID:
https://bugs.openjdk.java.net/browse/JDK-8209189
Webrev:
cr.openjdk.java.net/~eosterlund/8209189/webrev.00/
Thanks,
/Erik
More information about the hotspot-dev
mailing list