RFR(L): 8195097: Make it possible to process StringTable outside safepoint

Robbin Ehn robbin.ehn at oracle.com
Mon Jun 4 15:17:08 UTC 2018


Hi Gerard,

On 2018-05-31 22:06, Gerard Ziemski wrote:
> hi Robbin,
> 
> I just started reviewing and need another daye for more in-depth review, but right now I wanted to start a conversation about 2 runtime flags that we seem to longer use in the new code:
> 
> 
> #1 VerifyStringTableAtExit
> 
> I think we should be able to add the code back that verifies the table in this new implementation, right? (i.e StringTable::verify_and_compare_entries)

Added it back.

> 
> 
> #2 StringTableSize
> 
> We either need to deprecate it, or keep, but change the behavior (to take a power of 2). If we change the behavior, then we need to document it in release notes. I personally favor keeping the option, despite the fact that the new table is capable to resize on its own.

Added support for this thanks for noticing I missed this.

Thanks, Robbin

> 
> 
> cheers
> 
> 
> 
>> On May 28, 2018, at 8:19 AM, Robbin Ehn <robbin.ehn at oracle.com> wrote:
>>
>> Hi all, please review.
>>
>> This implements the StringTable with the ConcurrentHashtable for managing the
>> strings using oopStorage for backing the actual oops via WeakHandles.
>>
>> The unlinking and freeing of hashtable nodes is moved outside the safepoint,
>> which means GC only needs to walk the oopStorage, either concurrently or in a
>> safepoint. Walking oopStorage is also faster so there is a good effect on all
>> safepoints visiting the oops.
>>
>> The unlinking and freeing happens during inserts when dead weak oops are
>> encountered in that bucket. In any normal workload the stringtable self-cleans
>> without needing any additional cleaning. Cleaning/unlinking can also be done
>> concurrently via the ServiceThread, it is started when we have a high ‘dead
>> factor’. E.g. application have a lot of interned string removes the references
>> and never interns again. The ServiceThread also concurrently grows the table if
>> ‘load factor’ is high. Both the cleaning and growing take care to not prolonging
>> time to safepoint, at the cost of some speed.
>>
>> Kitchensink24h, multiple tier1-5 with no issue that I can relate to this
>> changeset, various benchmark such as JMH, specJBB2015.
>>
>> Issue: https://bugs.openjdk.java.net/browse/JDK-8195097
>> Webrev: http://cr.openjdk.java.net/~rehn/8195097/v0/webrev/
>>
>> Thanks, Robbin
> 


More information about the hotspot-runtime-dev mailing list