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

Robbin Ehn robbin.ehn at oracle.com
Thu Jun 7 09:57:46 UTC 2018


Thanks, Gerard!

Fixed below.

/Robbin

On 2018-06-05 20:27, Gerard Ziemski wrote:
> hi Robbin,
> 
> A few minor issues for which I don't need to see a webrev:
> 
> 
> #1 Change:
> 
>   log_trace(stringtable)("Started to growed");
> 
> to
> 
>   log_trace(stringtable)("Started to grow");
> 
> 
> #2 Add white space after "while” from (there is one more instance of this):
> 
>   while(gt.doTask(jt)) {
> 
> to
> 
>   while (gt.doTask(jt)) {
> 
> 
> #3 Change:
> 
>   log_debug(stringtable)("Growed to size:" SIZE_FORMAT, _current_size);
> 
> to
> 
>   log_debug(stringtable)("Grown to size:" SIZE_FORMAT, _current_size);
> 
> 
> #4 "nearest_pow_2" is inaptly named, if the user passes "129" we select "256", not "128", so maybe rename it to "ceil_pow_2”?
> 
> 
> PS. I would have liked to see whether Netbeans or Eclipse trigger the table resizing during the startup, but I was unable to trivially run either of them using jdk11, oh well.
> 
> 
> cheers
> 
>> On Jun 4, 2018, at 10:59 AM, Robbin Ehn <robbin.ehn at oracle.com> 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