RFR: 8212879: Make JVMTI TagMap table concurrent [v4]

[Coleen Phillimore]

On Wed, 4 Nov 2020 09:27:39 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> 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 purely non-copying collectors, but G1 concurrent oldgen collection is non-copying.)  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.

The new rehash function also doesn't move the objects either.  It essentially does the same as the old weak_oops_do function.

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

PR: https://git.openjdk.java.net/jdk/pull/967