On Wed, 23 Sep 2020 08:33:20 GMT, Erik Österlund <eosterl...@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
