RFR: 8296875: Generational ZGC: Refactor loom code [v3]

[Richard Reingruber]

On Thu, 17 Nov 2022 09:23:48 GMT, Erik Österlund <eosterlund at openjdk.org> wrote:

>> src/hotspot/share/gc/shared/barrierSetStackChunk.cpp line 68:
>> 
>>> 66: 
>>> 67:   virtual void do_oop(oop* p) override {
>>> 68:     if (UseCompressedOops) {
>> 
>> Wouldn't it be better to hoist the check for `UseCompressedOops`?
>
> The compiler should be able to do that already. We devirtualize calls into oop closures, and the closure is stack allocated. So the compiler should be able to do that if it finds that it is a good idea. I'd prefer to leave that to the compiler.

`CompressOopsOopClosure::do_oop()` and `FrameOopIterator::oops_do()` are defined in different compilation units. So calls to `do_oop()` cannot be devirtualized or am I missing something?
 Mistaken or not, I'm ok with this version.

>> src/hotspot/share/gc/shenandoah/shenandoahBarrierSetStackChunk.cpp line 30:
>> 
>>> 28: 
>>> 29: void ShenandoahBarrierSetStackChunk::encode_gc_mode(stackChunkOop chunk, OopIterator* oop_iterator) {
>>> 30:   // Nothing to do
>> 
>> Shenandoah allows `UseCompressedOops` enabled, doesn't it? Isn't it necessary then to do the encoding as in the super class?
>
> No we don't convert the oops for Shenandoah. Instead, Shenandoah's closures know how to deal with both oop* and narrowOop* on the heap, and will get passed the appropriate type of pointer. So it doesn't use the bitmap. I have tested that it works with Shenandoah as well.

Interesting and good to know.

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

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