RFR: 8290025: Remove the Sweeper [v3]

[Vladimir Kozlov]

On Thu, 4 Aug 2022 20:50:14 GMT, Erik Österlund <eosterlund at openjdk.org> wrote:

> > Initial review of few `code/` files. Will do more later.
> > I am not comfortable with name `unloading` for this process because historically, for me, it is associated with class unloading and "unloading" corresponding nmethods. `cleaning` is more similar with `sweeping`. But it could be only me.
> 
> Thanks for reviewing this change! I'm using the term "code cache unloading", because that is what we have always called unloading of nmethods triggered by the GC. And now it is the GC that owns this completely, so code cache unloading is the way in which nmethods are freed. At least that was my reasoning. I'd like to split the "unloading" parts of the CodeCache to a separate file, but I decided it's better to do that in a separate patch, as this patch is large enough and I don't want to move around code as well in it. Hope this makes sense.

Okay, I agree since it is GC operation now.

>> src/hotspot/share/ci/ciEnv.cpp line 1212:
>> 
>>> 1210:   }
>>> 1211: 
>>> 1212:   NoSafepointVerifier nsv;
>> 
>> There is window after releasing all previous locks and here when nmethod could become dead. I don't see `post_compiled_method()` checking for that.
>> Also I don't see such `NoSafepointVerifier` in `JVMCIRuntime::register_method()`.
>
> The nmethod can only get unloaded at safepoint polls. There aren't any when unlocking. The reason the NSV isn't just crossing the entire scope, is because some locks like Compile_lock will block when we take the lock, just not when we unlock it.
> Unfortunately I can't put a similar NSV in the JVMCI installer, because when you run JVMCI with native image, there is a setter that uses JNI, which will check for safepoints. However, that only happens if the nmethod failed to install, which doesn't really matter, but it does prevent the NSV from being in the same corresponding location there.

I am talking about concurrent change of nmethod's state. When you **publish** nmethod (set Method::_code) and it is not locked it could be marked non-entrant. It depends on how OS's scheduler run/suspend this compiler's thread.
But you are right, unloading only happens in SFP. So the code should be still there and it is still alright to initialize tasks' fields.

`nmethod::post_compiled_method_load_event()` has `NoSafepointVerifier` already. Only task's fields settings is not covered. Do you think we still need it here?

-------------

PR: https://git.openjdk.org/jdk/pull/9741