JDK-6684579 : SoftReference processing can be made more efficient
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: hs10
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: x86
  • Submitted: 2008-04-04
  • Updated: 2010-04-02
  • Resolved: 2008-12-10
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 6 JDK 7 Other
6u14Fixed 7Fixed hs14Fixed
Related Reports
Relates :  
JDK-6684596 - +ParallelRefProcEnabled hangs in Reference processing phase
Relates :  
JDK-4214755 - (ref) JDK1.2 handling of nested refs seems to go against API spec
Relates :  
JDK-6778647 - snap{,_policy}() should be renamed setup{,_policy}()
Relates :  
JDK-6990442 - (ref) Regression to clearing of a softly reachable object
Relates :  
JDK-6687570 - 64-bit server compiler crashed in Parse::merge_exception
Description
There are two ways in which the performance problem encountered by the
customer (see display 1 in "Comments" section) can be ameliorated
via changes/improvements to SoftReference processing within
the GC subsystem, one of which is specific to concurrent collectors.

The customer's application has, meanwhile, taken steps at the application
level to avoid (workaround) this performance problem.

A simple test case will be attached to this bug, illustrating the problem,
and will serve to highlight the performance improvement as a result of
the "Suggested Fix".
Comments
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/c96030fff130
21-11-2008
EVALUATION 6684579 SoftReference processing can be made more efficient bug: http://bugs.sun.com/view_bug.do?bug_id=6684579 webrev: http://webrev.invokedynamic.info/ysr/6684579/ It turns out that, at least for current soft reference clearing policies where the soft-ref master clock is advanced only at each major GC, we can decide accurately (always for stop-world collectors, and for all current clearing policies also for concurrent collectors) whether a soft reference should not be cleared at the point at which the reference object is first discovered. This moves at least some of the load from the final reference processing phase into the marking phase (concurrent marking phase for the concurrent collectors) making for shorter GC pauses on account of processing SoftReference objects. For the specific, albeit somewhat extreme, case of this customer using the CMS collector the improvement was quite dramatic, going from 26 seconds to about 120 ms. In most cases, the performance improvement will be more modest depending on the size and population of soft references in the heap. Although the number of lines and files touched is rather large, the changes are wide and shallow, rather than deep, and mainly involve a change in the interface presented by some of the ReferenceProcessor methods to allow for the use of a soft ref policy object in the ReferenceProcessor object, rather than being a parameter to the processing methods. Thanks for your reviews. -- ramki
17-11-2008
SUGGESTED FIX <deleted>
04-11-2008
EVALUATION Customer has tested the preliminary fix and is satisfied with the performance. The fix will be inegrated after due review and testing.
25-06-2008
SUGGESTED FIX http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/c96030fff130
11-04-2008
EVALUATION See display 1 of "Comments" section; this is a day 0 performance bug, so will be present in all JVM's ever shipped from Sun to date and will be exhibited by all collectors in the JVM's shipped.
04-04-2008
SUGGESTED FIX 6684579 SoftReference processing can be made more efficient bug: http://bugs.sun.com/view_bug.do?bug_id=6684579 webrev: http://webrev.invokedynamic.info/ysr/6684579/ It turns out that, at least for current soft reference clearing policies where the soft-ref master clock is advanced only at each major GC, we can decide accurately (always for stop-world collectors, and for all current clearing policies also for concurrent collectors) whether a soft reference should not be cleared at the point at which the reference object is first discovered. This moves at least some of the load from the final reference processing phase into the marking phase (concurrent marking phase for the concurrent collectors) making for shorter GC pauses on account of processing SoftReference objects. For the specific, albeit somewhat extreme, case of this customer using the CMS collector the improvement was quite dramatic, going from 26 seconds to about 120 ms. In most cases, the performance improvement will be more modest depending on the size and population of soft references in the heap. Although the number of lines and files touched is rather large, the changes are wide and shallow, rather than deep, and mainly involve a change in the interface presented by some of the ReferenceProcessor methods to allow for the use of a soft ref policy object in the ReferenceProcessor object, rather than being a parameter to the processing methods. Thanks for your reviews. -- ramki
04-04-2008
WORK AROUND Avoid using "heavy" SoftReference subgraphs that have the referent link as an articulation point (i.e. the heavy subgraph is not otherwise strongly reachable).
04-04-2008