[14] RFR(s) : 8234173: assert(loader != __null && oopDesc::is_oop(loader)) failed: loader must be oop

[Markus Gronlund]

Hi Sangheon,

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)?

Thanks
Markus

> 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
> 
> Thanks,
> Sangheon
> 
> 
>