On Wed, 4 Nov 2020 07:52:12 GMT, Kim Barrett <kbarr...@openjdk.org> wrote:
>> So the design is that when the oops have new addresses, we set a flag in the >> table to rehash it. Not sure why this is wrong and why wouldn't it work for >> shenandoah? @zhengyu123 ? When we call WeakHandle.peek()/resolve() after >> the call, the new/moved oop address should be returned. Why wouldn't this >> be the case? > > I didn't say it "doesn't work for shenandoah", I said it wouldn't have worked > with the old shenandoah barriers without additional work, like adding calls > to resolve. I understand the design intent of notifying the table management > that its hash codes are out of date. And the num-dead callback isn't the > right place, since there are num-dead callback invocations that aren't > associated with hash code invalidation. (It's not a correctness wrong, it's > a "these things are unrelated and this causes unnecessary work" wrong.) It used to be that jvmti tagmap processing was all-in-one (in GC weak reference processing, with the weak clearing, dead table entry removal, and rehashing all done in one pass. This change has split that up, with the weak clearing happening in a different place (still as part of the GC's weak reference processing) than the others (which I claim can now be part of the mutator, whether further separated or not). "Concurrent GC" has nothing to do with whether tagmaps need rehashing. Any copying collector needs to do so. A non-copying collector (whether concurrent or not) would not. (We don't have any of those in HotSpot today.) And weak reference clearing (whether concurrent or not) has nothing to do with whether objects have been moved and so the hashing has been invalidated. There's also a "well known" issue with address-based hashing and generational or similar collectors, where a simple boolean "objects have moved" flag can be problematic, and which tagmaps seem likely to be prone to. The old do_weak_oops tries to mitigate it by recognizing when the object didn't move. ------------- PR: https://git.openjdk.java.net/jdk/pull/967
