RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v2]

[Erik Österlund]

On Wed, 23 Sep 2020 08:33:20 GMT, Erik Österlund <eosterlund at openjdk.org> wrote:

>> src/hotspot/share/compiler/oopMap.cpp line 243:
>> 
>>> 241:   } else {
>>> 242:     all_do(fr, reg_map, f, process_derived_oop, &do_nothing_cl);
>>> 243:   }
>> 
>> I wonder if we shouldn't hide the StackWatermarkSet in the GC code, and not "activate" the DerivedPointerTable when a
>> SWS is used? Isn't it the case that already don't enable the table for ZGC? Couldn't this simply be: `
>>   if (DerivedPointerTable::is_active()) {
>>     all_do(fr, reg_map, f, add_derived_oop, &do_nothing_cl);
>>   } else {
>>     all_do(fr, reg_map, f, process_derived_oop, &do_nothing_cl);
>>   }
>> `
>
> The problem isn't the GC code deciding to use or not use the derived pointer "table". It's the shared code uses of it
> that is the problem here. The table is explicitly activated by shared code, when for example using the JFR leak
> profiler, JVMTI heap walks, etc. This code makes the selection a GC choice when invoked by GC code, and a shared
> runtime choice when invoked by the shared runtime.

After discussions off-line, I think passing in an explicit derived pointer iteration mode into oops_do, is much better
than trying to figure out who the caller is from this context.

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

PR: https://git.openjdk.java.net/jdk/pull/296