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

coleen.phillimore at oracle.com coleen.phillimore at oracle.com
Tue Jun 5 18:57:44 UTC 2018

This latest version looks good to me also.

On 6/4/18 11:59 AM, Robbin Ehn wrote:
> Hi,
> Here is an updated after reviews:
> Inc : http://cr.openjdk.java.net/~rehn/8195097/v2/inc/webrev/
> Full: http://cr.openjdk.java.net/~rehn/8195097/v2/full/webrev/
> Passed tier 1-3.
> /Robbin
> On 2018-05-28 15:19, Robbin Ehn 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