Re: [14] RFR(s) : 8234173: assert(loader != __null && oopDesc::is_oop(loader)) failed: loader must be oop
Sorry, I sent to wrong alias. Resent to runtime. Thanks, Sangheon On 1/15/20 11:57 AM, sangheon@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 Thanks, Sangheon
[14] RFR(s) : 8234173: assert(loader != __null && oopDesc::is_oop(loader)) failed: loader must be oop
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 Thanks, Sangheon
