RFR: 8290025: Remove the Sweeper [v3]

[Erik Österlund]

On Thu, 4 Aug 2022 20:10:16 GMT, Vladimir Kozlov <kvn 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.

> src/hotspot/share/ci/ciEnv.cpp line 1076:
> 
>> 1074: 
>> 1075:     // Notify code cache unloading that we are about to allocate, which may
>> 1076:     // or may not require freeing up memory first.
> 
> Confusing comment. As I understand it could be: `Check if memory should be freed before allocation`.

Fixed.

> src/hotspot/share/code/codeCache.cpp line 700:
> 
>> 698: // used in order to not be classed as cold.
>> 699: void CodeCache::update_cold_gc_count() {
>> 700:   if (!MethodFlushing || !UseCodeCacheFlushing || NmethodSweepActivity == 0) {
> 
> Did you test these cases?

Yes.

> src/hotspot/share/code/codeCache.cpp line 779:
> 
>> 777: }
>> 778: 
>> 779: void CodeCache::on_allocation() {
> 
> How about `CodeCache::gc_on_allocation()`? Otherwise it is not clear what it does in places where it is called.

Fixed.

> src/hotspot/share/compiler/compilationLog.hpp line 1:
> 
>> 1: /*
> 
> Is it Git hiccup with the file renaming?

Yes, haha.

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

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