RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v2]
Erik Österlund
eosterlund at openjdk.java.net
Wed Sep 23 13:50:30 UTC 2020
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
More information about the serviceability-dev
mailing list