JDK-8027455 : Improve symbol table scan times during gc pauses
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: hs25,8
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2013-10-29
  • Updated: 2014-09-19
  • Resolved: 2014-01-20
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
7u60Fixed 8u20Fixed 9 b03Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
The symbol table stores references to symbols. Each of these symbols is reference counted; if the reference count of a symbol reaches zero, it can be removed.

Currently, the symbol table is cleaned up during various GC pauses, as it provides a convenient opportunity where no random modification by other threads can occur.

However, particularly because this cleanup process is serial, it takes a long time. In particular across a large range of FMW applications (see attached log file), it takes 50% of remark pause time, which is way too high.

Symbol table scan/scrubbing pause time must be improved; there are several options for this:

- parallelize this task
- incrementally scrub the symbol table (i.e. only parts at once) given e.g. a time allowance
- maybe move it or parts of it, e.g. just finding the scrub-able entries, to a concurrent task

This particular CR focuses on parallelizing existing work. JDK-8031565 is going to try to do this work during other pauses.

Another option would be truly concurrent cleanup of the table, i.e. when the refcount reaches zero, unlink the symbol. This need not be done for every symbol reaching zero, but e.g. on every n-th symbol reaching zero, possibly storing references to the affected symbols somewhere.

Actually in case of G1 remark and no class unloading, possibly this step can be skipped altogether as well. I.e. assuming that the (only?) source of symbols is class loading, if there is no unloading, nothing could have been changed here. May not be true for special cases like anonymous class loading or other sources of symbols.