Details
-
Enhancement
-
Resolution: Fixed
-
P3
-
16
-
b26
Description
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.
Attachments
Issue Links
- 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