United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-8027455 : Improve symbol table scan times during gc pauses

Details
Type:
Enhancement
Submit Date:
2013-10-29
Status:
Resolved
Updated Date:
2014-07-29
Project Name:
JDK
Resolved Date:
2014-01-20
Component:
hotspot
OS:
Sub-Component:
gc
CPU:
Priority:
P3
Resolution:
Fixed
Affected Versions:
hs25,8
Fixed Versions:

Related Reports
Backport:
Backport:
Backport:
Backport:
Backport:
Backport:
Relates:
Relates:
Relates:
Relates:
Relates:

Sub Tasks

Description
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

                                    

Comments
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.
                                     
2013-10-29
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.
                                     
2013-10-30
This particular CR focuses on parallelizing existing work. JDK-8031565 is going to try to do this work during other pauses.
                                     
2014-01-13
URL:   http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/893ce66f7473
User:  tschatzl
Date:  2014-01-20 11:46:37 +0000

                                     
2014-01-20
URL:   http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/893ce66f7473
User:  lana
Date:  2014-02-11 20:38:10 +0000

                                     
2014-02-11



Hardware and Software, Engineered to Work Together