JDK-8213229 : Investigate treating StringTable as weak in young collections
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2018-11-01
  • Updated: 2019-08-13
  • Resolved: 2019-01-29
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.
JDK 13
13 b06Fixed
Related Reports
Blocks :  
JDK-8217578 - Shenandoah cleanup unused timings after concurrent string table change
Relates :  
JDK-8221558 - Remove obsolete uses of OopStorage::ParState _par_state
Relates :  
JDK-8037956 - Merge String Deduplication work with String/Symbol table work
Relates :  
JDK-8217522 - Missing barriers in some java_lang_String assertion code after JDK-8217442
Relates :  
JDK-8213752 - Determine StringTable content liveness concurrently in G1
Relates :  
JDK-8215709 - WeakProcessor should also report task item information
Relates :  
JDK-8217778 - StringTable cleanup miscalculates amount of dead objects
Relates :  
JDK-8213198 - Not triggering concurrent cycle in G1 leaves string table cleanup deferred
Description
Current STW collectors presently treat the StringTable as a strong root in young collections. This avoids the need to walk the StringTable and delete dead entries in a young collection. Instead it walks the StringTable and marks all the strings, as one of the in-parallel root marking phases.

With the recent reimplementation of the StringTable using ConcurrentHashtable and OopStorage, treating it as a strong root rather than a weak root in young collections may no longer provide best performance.