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

[coleen.phillimore at oracle.com]

On 1/4/19 8:28 AM, Erik Österlund wrote:
> 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.

Ah, ok.  I was getting this mixed up with the cld_unloading_do() calls 
in jfr.  This is called by do_unloading.
Looks strange but good.  This is for 12 right?
Thanks,
Coleen
>
> 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
>>
>