RFR (M): 8027476: Improve performance of Stringtable unlink, 8027455: Improve symbol table scan times during gc pauses

[Bengt Rutisson]

Hi Thomas,

Looks good. Great work!

A couple of minor things. I'll leave it up to you if you want to do any 
changes. I'm fine with the patch as it is.


G1TraceStringSymbolTableScrubbing is now experiemental. It looks like it 
is more common to have Trace flags be diagnostic. Do you mind changing 
to diagnostic?


g1CollectedHeap.cpp

5248         StringTable::unlink(_is_alive, &strings_processed, 
&strings_removed);
5249         _strings_processed = strings_processed;
5250         _strings_removed = strings_removed;

Maybe the single threaded case could do?

StringTable::unlink(_is_alive, &_strings_processed, &_strings_removed);

Then these local variables could move in inside the 
G1CollectedHeap::use_parallel_gc_threads() check.

5230     size_t strings_processed = 0;
5231     size_t strings_removed = 0;
5232     size_t symbols_processed = 0;
5233     size_t symbols_removed = 0;

Thanks,
Bengt

On 1/10/14 10:27 AM, Thomas Schatzl wrote:
> Hi all,
>
>    could I have reviews for the following performance change?
>
> It implements parallelization of string table and symbol table scan
> during G1 full GC and remark.
>
> This decreases the respective string table/symbol table scan times
> almost linearly depending on the number of threads used.
>
> The change is quite straightforward, similar to string table scan during
> initial mark there are new possibly_parallel_unlink() methods for both
> string and symbol table, that are later used in a new taskset.
>
> Task distribution works as before, using a single claim value for each
> of the tables (reusing the one for the string table) on the hash table
> array.
>
> The impact on total remark/full gc time is significant, in conjunction
> with JDK-8027454 (RFR coming soon) remark time is halved.
>
> I decided to merge these two fixes into a single webrev because these
> two things are closely related, and the shared code between the two
> issues is very large, and the actual code to implement one or the other
> is small and easily understood (imo). Splitting would add lots of code
> that would first need to be added and then removed again too.
>
> I filed two follow-up CRs to use these new methods in the other parallel
> collectors too (JDK-8031473), and another one for fine-tuning
> (JDK-8031472) some parameters.
>
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8027476/webrev
>
> CRs:
> https://bugs.openjdk.java.net/browse/JDK-8027455
> https://bugs.openjdk.java.net/browse/JDK-8027476
>
> Testing:
> test case, jtreg, FMW apps, specjbb2005, specjbb2013, dacapo, and lots
> of other testing in the recent months
>
> Thanks,
>    Thomas
>
>