RFR: 8209189: Make CompiledMethod::do_unloading more concurrent

[David Holmes]

Hi Erik,

Just a follow-up on this change. It seems that the 
CodeCacheUnloadingTask::_lock is now unused - is that correct? (You 
(accidentally?) made it non-private as part of this change.)

I was moving that lock as part of the static initalization cleanup, but 
will just delete it if now unused.

Thanks,
David

On 20/10/2018 12:22 AM, Erik Österlund wrote:
> 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