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