On Mon, 14 Sep 2020 14:20:29 GMT, Erik Österlund <eosterlund@openjdk.org> wrote:
Shenandoah changes are not complete: /home/rkennke/src/openjdk/jdk/src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp: In member function 'virtual void ShenandoahFinalMarkingTask::work(uint)': /home/rkennke/src/openjdk/jdk/src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp:298:31: error: 'oops_do' is not a member of 'ObjectSynchronizer' ObjectSynchronizer::oops_do(&resolve_mark_cl); ^~~~~~~ /home/rkennke/src/openjdk/jdk/src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp:308:31: error: 'oops_do' is not a member of 'ObjectSynchronizer' ObjectSynchronizer::oops_do(&mark_cl); ^~~~~~~ I will have a look into how to resolve this. In order to fix this, I need one of two things: ``` * A way to iterate oops of the global-list. Explanation: In Shenandoah's I-U mode, we need to re-mark such ObjectMonitors during final-mark because they may be the only remaining reference to an object on the heap. _or_ (even better)
* Call a write-barrier (IN_NATIVE) whenever an ObjectMonitor is moved to the global-list upon thread-destruction. This way we could mark that object concurrently. ```
Notice that this does not affect thread-local ObjectMonitors (IOW, most regular ObjectMonitors) because those would be scanned while scanning thread stacks. Therefore I'd like to avoid to generally place a barrier in ObjectMonitor. See: https://bugs.openjdk.java.net/browse/JDK-8251451 AFAICT, this may affect ZGC too (not 100% sure about this).
So this change makes the object monitors weak. So you shouldn't have to remark them at all. If they hold the last reference to the object, then the monitor gets the object cleared as part of normal weak OopStorage reference processing. Subsequent deflation cycles will detect that the GC has cleared the oop, and reuse the monitor. In other words, we should just remove the call to the oops_do function, and rely on OopStorage doing its thing. The GC should not have to care at all about monitors any longer, only about processing weak OopStorages, which is done automatically. Hope this makes sense.
Yes, definitely. I came to the same conclusion. Thank you! With the patch amended: http://cr.openjdk.java.net/~rkennke/8247281-shenandoah.patch I'm good with the change. ------------- PR: https://git.openjdk.java.net/jdk/pull/135