Parallelizing symbol table/string table scan

[Thomas Schatzl]

Hi,

On Mon, 2013-11-11 at 11:28 -0500, Coleen Phillimore wrote:
> On 11/11/2013 11:19 AM, Thomas Schatzl wrote:
> > Hi,
> >
> > On Mon, 2013-11-11 at 10:53 -0500, Coleen Phillimore wrote:
> >> 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%.
> >> Why do you scan the symbol table during remark?   It doesn't contain any
> >> oops.
> > At the end of remark we scrub it for entries with zero refcount - we do
> > that at the end of every non-young GCs at the moment.
> 
> Ok, so it's only non-young collections.  That's what I thought.

That unfortunately includes G1 remark... however particularly in g1, if
there is pause time left (or reserve a few ms after a class unloading
remark pause until complete), we could do partial symbol table scrubbing
there instead of in the remark.

> > I *think* the reasoning was that particularly after class unloading
> > there will be freed symbols, so why not do the symbol scrubbing there as
> > well. I also *think* that this has been placed there mostly for
> > convenience (good opportunity since the application is in a STW pause
> > already).
> 
> I'll read and reply to the rest of your message, but you are right, 
> _most_ of the symbols are going to be unreferenced during class 
> unloading.   And it has to be during a safepoint (stop the world).
> Are there symbol table walks that aren't after class unloading?

Symbol (and string) table scrubbing is always placed after class
unloading in the code.

All "full gcs" but CMS do both class unloading and symbol table scan
unconditionally it seems. So when the ClassUnloading global is set to
false, symbol table scrubbing is done anyway always; I hope that CMS is
properly synchronized with that - it does not seem so.

No, it isn't :( At least Klass::clean_weak_klass_links() only checks for
ClassUnloading. Also during root processing/class loader data graph root
scan with CMSClassUnloading set to true and ClassUnloading set to false
it seems you can probably get interesting results...

There is also a UnlinkSymbols VM pause that looks unused.

Thomas