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