JDK-8173013 : JVMTI tagged object access needs G1 pre-barrier
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2017-01-19
  • Updated: 2019-01-14
  • Resolved: 2017-02-10
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 10 JDK 8 JDK 9
10Fixed 8u192Fixed 9 b159Fixed
Related Reports
Relates :  
JDK-8166188 - G1 Needs pre barrier on dereference of weak JNI handles
Description
JvmtiTagHashmapEntry has a bare oop member. These are weak references.  Any place that allows that oop to "escape" needs the G1 pre-barrier.

GetObjectsWithTags provides such an escape path. All other accesses to that oop appear to be "peek" operations, where the oop is locally examined without any possibility of a safepoint while it's being used.  Without that barrier, use of this JVMTI function with G1 can lead to crashes.
Comments
Backportable to 8u: http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-April/007383.html
13-04-2018
It's a little bit late but [~stefank]'s reproducer above was good enough to provoke the problem to me as well. Thank you again.
10-02-2017
I've created a small reproducer for this bug: http://cr.openjdk.java.net/~stefank/8173013/reproducer/ Steps to reproduce: 1) Download the files 2) bash ObjectsWithTagsResurrectionBug.build.sh 3) JAVA_HOME=<fastdebug_java_home> bash ObjectsWithTagsResurrectionBug.run.sh The reproducer * tags an object * promotes it to old gen * drops the last strong reference to it * calls GetObjectsWithTags during concurrent mark to retrieve the tagged object * installs the retrieved object into the object graph * verifies that the heap is still consistent (which it isn't with this bug) * uses the object. The output when verification fails is: ---------- Field 0x0000000693000210 of live obj 0x0000000693000200 in region [0x0000000693000000, 0x0000000693200000) class name [Ljava.lang.Object; points to dead obj 0x00000005cc2d4098 in region [0x00000005cc200000, 0x00000005cc400000) class name java.lang.String # Internal Error (g1CollectedHeap.cpp:3365), pid=8969, tid=0x00007f60e2753700 # guarantee(!failures) failed: there should not have been any failures
31-01-2017