RFR(s): 8213574: Deadlock in string table expansion when dumping lots of CDS classes

Ioi Lam ioi.lam at oracle.com
Tue Nov 13 17:30:26 UTC 2018


Looks good! Thanks

- Ioi


On 11/13/18 8:54 AM, Robbin Ehn wrote:
> Sorry wrong url's:
>
> Inc:
> http://cr.openjdk.java.net/~rehn/8213574/2/inc/webrev/
>
> Full:
> http://cr.openjdk.java.net/~rehn/8213574/2/full/webrev/
>
> /Robbin
>
> On 11/13/18 5:53 PM, Robbin Ehn wrote:
>> Hi, here is small incremental update:
>>
>> http://rehn-ws.se.oracle.com/cr_mirror/8213574/2/inc/webrev/index.html
>>
>> Full:
>> http://rehn-ws.se.oracle.com/cr_mirror/8213574/2/full/webrev/
>>
>> Passes t1-3 and the reprod in 8213587.
>>
>> Thanks, Robbin
>>
>> On 11/12/18 2:59 PM, Robbin Ehn wrote:
>>> Hi all, please review.
>>>
>>> The re-sizing operation is run by the ServiceThread (JavaThread). To 
>>> be safepoint polite it pauses the operation and do safepoint checks. 
>>> Operations on
>>> the hashtable that visit multiple bucket are mutual exclusive. This 
>>> means you
>>> can't iterate over the table during a safepoint if there is paused 
>>> resize.
>>>
>>> The hashtable uses a Mutex, which means if there were other threads 
>>> using it
>>> during the safepoint the VM thread sneaking would break it. Since 
>>> there are no such users it is safe to access it without locks in 
>>> side the safepoint. That is
>>> how rehash works today.
>>>
>>> Until we sorted this out better in 8213742,  I'm adding a safepoint 
>>> scanning
>>> operation that can handle a paused resize and which skips the lock.
>>>
>>> CR: https://bugs.openjdk.java.net/browse/JDK-8213574
>>> Webrev: http://cr.openjdk.java.net/~rehn/8213574/webrev/
>>>
>>> Passes t1-3 and 8213587 new test which triggered the issue.
>>>
>>> Thanks, Robbin



More information about the hotspot-runtime-dev mailing list