RFR (S) 8218266: G1 crash in AccessInternal::PostRuntimeDispatch

[coleen.phillimore at oracle.com]

On 2/25/19 3:26 PM, zgu at redhat.com wrote:
> On Mon, 2019-02-25 at 15:04 -0500, coleen.phillimore at oracle.com wrote:
>> On 2/25/19 2:48 PM, zgu at redhat.com wrote:
>>> Hi Coleen,
>>>
>>> On Mon, 2019-02-25 at 13:44 -0500, coleen.phillimore at oracle.com
>>> wrote:
>>>> Summary: protection_domains can be unloaded in the dictionary
>>>> pd_set.
>>>>
>>>> Tested with test here:
>>>> test/hotspot/jtreg/runtime/Dictionary/ProtectionDomainCacheTest.j
>>>> ava
>>>> and
>>>> the test in the bug.  Also tested hs-tier1-3.
>>>>
>>>> open webrev at http://cr.openjdk.java.net/~coleenp/2019/8218266.0
>>>> 1/we
>>>> brev
>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8218266
>>> The fix looks good. But I feel a bit odd to place cleaning CLD's
>>> cached
>>> pd inside ProtectionDomainCacheTable.
>>>
>>> Would it be better to have ServiceThread calls e.g.
>>> SystemDictionary::clean_pd_cache(), and the method to cleanup CLD's
>>> cache pd and call ProtectionDomainCacheTable::unlink()?
>> You mean reverse these?  The trigger on the service thread is
>> something
>> inside the protection domain cache table though.
> After another look into the bug, I don't feel I have full grip of the
> problem. Therefore, I would like to withdraw my review.

Okay, I can try to explain it.  All of the dictionary entries point to a 
linked list of protection domains that were used to load the class.   
The elements in this list point directly to Hashtable entries in the 
ProtectionDomainTable.  The protection domains can be GC'd before the 
dictionary entry is unloaded, so that the elements in the linked list 
need to be cleaned out.  I chose cleaning to happen right before the 
protection domain cache table is cleaned up so that the entries are not 
dangling pointers.  Since the table is cleaned out concurrently now, I 
have to do the cleanup there so I know it's happened.

Thanks,
Coleen
>
> Sorry.
>
> -Zhengyu
>
>
>> Coleen
>>> Thanks,
>>>
>>> -Zhengyu
>>>
>>>> Thanks,
>>>> Coleen
>>