[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-runtime-dev
Subject:    Re: RFR(L): 8195097: Make it possible to process StringTable outside safepoint
From:       Gerard Ziemski <gerard.ziemski () oracle ! com>
Date:       2018-05-31 20:06:25
Message-ID: 4D8E57FA-AF13-4246-AE5B-6A310CB36C10 () oracle ! com
[Download RAW message or body]

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)


#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.


cheers



> On May 28, 2018, at 8:19 AM, Robbin Ehn <robbin.ehn@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


[prev in list] [next in list] [prev in thread] [next in thread]