RFR (L): 8213229: Investigate treating StringTable as weak in young collections

[Kim Barrett]

> On Jan 10, 2019, at 3:46 PM, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
> […]
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8213229
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8213229/webrev.1/
> Testing:
> hs-tier1-6, performance checking with our performance suite showed no
> particular performance differences before/after
> 
> Thanks,
>  Thomas

------------------------------------------------------------------------------
src/hotspot/share/gc/g1/g1ConcurrentMark.cpp
1660     // No need to clean string table as it is treated as strong root when
1661     // class unloading is disabled.

I think that comment needs updating.

------------------------------------------------------------------------------
src/hotspot/share/gc/g1/g1FullGCAdjustTask.hpp
  46   StringDedupCleaningTask  _cleaning_task;

Maybe _cleaning_task => _string_dedup_cleaning_task?

It's obvious here, but not so much where used.

------------------------------------------------------------------------------

I think this change has introduced a memory leak in the StringTable
OopStorage instance. The old code has calls to
StringTable::reset_dead_counter() and
StringTable::finish_dead_counter() in the StringCleaningTask
constructor and destructor, and StringTable::unlink_or_oops_do and
StringTable::possibly_parallel_unlink updated the dead counters.  This
resulted in notification of the ServiceThread when there was enough
StringTable OopStorage cleanup work to do (e.g. go through the
StringTable OopStorage instance looking for allocated entries with
NULL values, and deallocate them).

Nothing like that seems to be happening with these changes.  I
couldn't find anything that would trigger the ServiceThread's cleanup
behavior. 

What I was expecting was that the parallel WeakProcessor would
arrange for the closures it receives to be wrapped in counting
closures, with the counts being recorded in the
WeakProcessorPhaseTimes work items.  And then those counts would be
both reported in logging and also used in the StringTable case to
notify the StringTable of changes.

The serial WeakProcessor might do something similar, but I haven't
looked at it as much for this problem.

------------------------------------------------------------------------------