RFR(s) : 8234173: assert(loader != __null && oopDesc::is_oop(loader)) failed: loader must be oop
MARKUS.GRONLUND at ORACLE.COM
Thu Jan 16 08:25:58 UTC 2020
What (and if so how) is concurrently reading this? Since the operation of both clearing and resetting the mark word happens in a safepoint (only the VMThread running)?
> On 16 Jan 2020, at 03:01, sangheon.kim at oracle.com wrote:
> Hi all,
> Could I have some reviews for changing mark value of ObjectSampleMarker (part of JFR Leak Profiler)?
> The assertion is fired because the leak profiler(ObjectSampleMarker::mark()) puts an invalid mark word (0, INFLATING) into the oop and a concurrent user of oopDesc::is_oop() is reading the mark word which may diagnose the given object is not oop.
> In addition, there is a comment at oopDesc::is_oop() which supports that mark word shouldn't be zero at safepoint.
> // Header verification: the mark is typically non-zero. If we're
> // at a safepoint, it must not be zero.
> // Outside of a safepoint, the header could be changing (for example,
> // another thread could be inflating a lock on this object).
> Nobody writes to the mark word concurrently.
> Other GCs which support JFR have the same issue, but at the moment the test is only run with G1.
> In the patch, I am proposing to set mark word with 3 (mark bit value) instead of 0.
> CR: https://bugs.openjdk.java.net/browse/JDK-8234173
> webrev: http://cr.openjdk.java.net/~sangheki/8234173/webrev.0/
> Testing: hs-tier1 ~ 5, jdk-tier1 ~ 3, test/jdk/jdk/jfr and test/jdk/jdk/jfr/events/oldobject for 1200 iterations
More information about the hotspot-runtime-dev