Parallelizing symbol table/string table scan

[Coleen Phillimore]

Thomas, Now I read your mail...

On 11/11/2013 08:56 AM, Thomas Schatzl wrote:
> Hi all,
>
>    recently we (the gc team) noticed severe performance issues with
> symbol table and string table scan during remark.
>
> Basically, in G1 these pauses are the largest pauses on a reasonably
> tuned system. Also, in particular, symbol table scan alone takes 50% of
> total remark time. String table scan takes another 13%.
>
> At least symbol table scan is a pretty big issue.
>
> The simple approach to those is to parallelize these tasks of course,
> however I would like to query you for comments or suggestions :)
> (I am simply throwing some ideas on the wall, in the hope something
> sticks...)
>
> One idea that came up to optimize that further has been to not do string
> table or symbol table scrubbing after gc at all if no class unloading
> has been done, assuming that the amount of dead entries are zero anyway.

For Symbol tables it's not zero but pretty close.  Karen reminded me 
that TempNewSymbols can get zero refcounts without class unloading but 
there aren't many of these.   I found only 3% of symbols at best were 
reclaimed running something with a lot of class loaders and symbols 
introduced by them (runThese -jck) so less scanning seems like a good 
thing to do.

String tables might still need scanning.   It would be good to know how 
many are reclaimed when you do.

It appears that Stefan has done some work to optimize StringTable scanning:
StringTable::possibly_parallel_oops_do


>
> This is (imo) true for the string table at least (because they are
> strong roots if not doing class unloading), but I am not so sure about
> the symbol table.
> You probably have more experience about the use of the symbol table, so
> any ideas what could cause symbol table entries to get stale other than
> class unloading, and if so, is this a big concern?

It's mostly class unloading, as above...
>
> Another option would be to do this symbol table scrubbing only after a
> certain amount of operations on the symbols, not sure if there is an
> indicator (that does not decrease perf for retrieving too much) for
> that.
>
> Another idea, again for the symbol table is to scrub it either
> incrementally (eg. depending on available time), or concurrently. I.e.
> some background task periodically waking up and scrubbing (parts of) the
> symbol table.

This is an interesting idea.   We could do incremental scrubbing when we 
take out the SymbolTable_lock when adding a symbol.   Have some flag 
like _classunloading_occurred and scrub just the bucket you're adding to 
(?).

See how much time you save avoiding SymbolTable scanning except during 
class unloading first though.   I do believe most of this work isn't 
necessary given the amount of memory you reclaim.  The trouble is that 
we have to worry about the degenerate case where somebody adds a symbol 
that takes a lot of memory that should be deallocated.

Coleen


>
> Comments, suggestions?
>
> I also created a few RFEs for these issues, see
>
> Symbol table:
> https://bugs.openjdk.java.net/browse/JDK-8027455
> https://bugs.openjdk.java.net/browse/JDK-8027543
> String table:
> https://bugs.openjdk.java.net/browse/JDK-8027454
> https://bugs.openjdk.java.net/browse/JDK-8027476
>
> Thomas
>