Bug ID: JDK-8212879 Make JVMTI TagMap table concurrent

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 16
16 b26Fixed

And use WeakHandles to point to the elements so that hashing doesn't have to be redone for GC.

If we use OopStorage via WeakHandles, the GC can walk the oops concurrently.  The oops were stored directly because there were unexpected NULL entries when they were jweak.  I don't see why this would be a problem, except that the hashcode would be broken in this case.  Making them use oop->identity_hash() would fix this.   Unfortunately, identity_hash is the only hashcode that makes sense for any sort of oop that can be stored in the table.

This anomalous table and its handling by GC is a problem area.

Fix request [17u] on behalf of Andrew Dinn Required follow up of JDK-8256811.
28-10-2022
Changeset: ba721f5f Author: Coleen Phillimore <coleenp@openjdk.org> Date: 2020-11-19 14:30:02 +0000 URL: https://github.com/openjdk/jdk/commit/ba721f5f
19-11-2020
Reopening. Removing GC interaction with this special table would remove the last serial phase for ZGC. from [~eosterlund] This root set is the only remaining root set that is processed in safepoints. And it is processed partially as strong and partially as weak, depending on caller, due to the weird fact that it is weak, but we can't treat it like a normal weak, because relocation pauses have to update all oops and rehash the table as well. So Per was wondering if anyone had any ideas about how to move it to OopStorage and turn it into something less special.
08-10-2020
We've decided not to fix this. Calling object->identity_hash() on all the things that could be tagged by the tag map table would cause an unknown large number of things to have to have inflated locks. The lock shares the markOop with the hash code in objects. There are also asserts that one can't call object->identity_hash() inside a safepoint, which is what the heap walker, one of the clients of this table, does. The table is walked directly by GC in a serial phase so that the weak oops can be cleared and the jvmti notification function is called at the time of the GC. Deferring this notification could defer it to a time when the jvmti environment is no longer active. The client code (tests) do not expect this. So GC might as well also rehash the table when the oop address changes since GC has to walk the table. Lastly, this has a different hashtable than the ones in our utilities, which isn't nice, but hasn't had a lot of bugs so isn't a maintenance problem. Closing as WNF.
01-07-2019
[~eosterlund] might be able to fill in the problems that we keep encountering wrt to the GCs.
23-10-2018

Relates :	JDK-8256651 - nsk_jvmti_aod_disableEvent{s}AndFinish should pass address of success
Relates :	JDK-8256688 - Shenandoah: Lock rank inversion after JDK-8212879
Relates :	JDK-6458402 - 3 jvmti tests fail with CMS and +ExplicitGCInvokesConcurrent
Relates :	JDK-8282459 - Debug agent CLASS_UNLOAD event handling should attempt to deliver events on dedicated debug agent thread
Relates :	JDK-8256072 - Eliminate JVMTI tagmap rehashing
Relates :	JDK-8256830 - misc tests failed with "assert(env->is_enabled(JVMTI_EVENT_OBJECT_FREE)) failed: checking"
Relates :	JDK-8256813 - Simplify WeakProcessor counting of OopStorage entries
Relates :	JDK-8256814 - WeakProcessorPhases may be redundant
Relates :	JDK-8256825 - Cleanup WeakProcessorPhaseTimes
Relates :	JDK-8257676 - Simplify WeakProcessorPhase
Relates :	JDK-8256811 - Delayed/missed jdwp class unloading events
Relates :	JDK-8256664 - Shenandoah: Cleanup after JDK-8212879