RFR: 8158871: Long response times with G1 and StringDeduplication

Thomas Schatzl thomas.schatzl at oracle.com
Tue Jun 14 14:02:53 UTC 2016

Hi Per,

  some quick initial comments:

On Tue, 2016-06-14 at 14:18 +0200, Per Liden wrote:
> Hi,
> Received some comments off-line and here's an updated webrev:
> http://cr.openjdk.java.net/~pliden/8158871/webrev.1/
> Main difference is that the overflow list now lives next to the cache
> list, rather than inside the cache list.

  - did you ever measure how long the deletion of all entries could
take? It does not try to synchronize for safepoints, so potentially
could delay safepoint for a long time.
(in G1StringDedupEntryCache::delete_overflowed)

  - I would kind of prefer
if G1StringDedupEntryCache::G1StringDedupEntryCache() would call
set_max_size() to set _max_list_lengths instead of duplicating the code
in the initialization list. 

  - any concurrent kind of work should have log message at the
beginning and the end of that work, otherwise it may be hard to find
out what the process is doing from the log (i.e. delaying the
safepoint) at the moment.

  - I am not sure if the default value of max_cache_size are good
values. I mean, if you have lots of threads (we are running on machines
with 2k+ threads already), the cache size will be zero by default.


More information about the hotspot-gc-dev mailing list