RFR: 8215773: applications/kitchensink/Kitchensink.java crash with "assert(ZAddress::is_marked(addr)) failed: Should be marked"

Erik Österlund erik.osterlund at oracle.com
Fri Jan 4 13:28:03 UTC 2019


Hi Coleen,

On 2019-01-04 13:37, coleen.phillimore at oracle.com wrote:
>
> Hi Erik,  This is kind of creepy.  They use the dead mirror and call 
> identity hash on it, which writes to the dead mirror.

Yup, that's right. This is equivalent to how during code cache 
unloading, possibly dead java.lang.invoke.CallSite objects are chased 
down, and their possibly dead CallSiteContext are queried so that we can 
write to its dependency context. It is creepy indeed, but is completely 
safe to do in the context it is done in, as the same thread performing 
the accesses, is the thread that will eventually free the memory of the 
dead objects. And in that incident, I did the same thing: use 
AS_NO_KEEPALIVE when peeking at the dead objects.

> Are these functions called at a safepoint?  Maybe JFR could do 
> something different here.

Yeah, they are called from safepoints with STW-unloading, and called by 
the ZDriver (the concurrent GC thread controlling the GC phases), during 
concurrent class unloading.

Thanks,
/Erik

> Coleen
>
>
> On 1/4/19 5:10 AM, Erik Österlund wrote:
>> Hi,
>>
>> During SystemDictionary::do_unloading(), JFR pokes around at the dead 
>> mirror oops that died due to class unloading.
>> The mirror is loaded without AS_NO_KEEPALIVE, which makes ZGC load 
>> barriers a bit sad, because they dislike loading dead oops.
>>
>> The solution is to load these mirrors with AS_NO_KEEPALIVE 
>> decorators, indicating that it is okay for them to be dead as we are 
>> only peeking at them. This is fine to do during concurrent execution 
>> by the GC thread that is performing class unloading, and hence 
>> controls the GC cycle, making sure that the memory of the dead oops 
>> is not reclaimed until the accesses have safely finished.
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8215773
>>
>> Webrev:
>> http://cr.openjdk.java.net/~eosterlund/8215773/webrev.00/
>>
>> Manually ran kitchensink 24 hours to make sure this doesn't happen 
>> again. And hs-tier1-6 on linux.
>>
>> Thanks,
>> /Erik
>



More information about the hotspot-runtime-dev mailing list