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".
Posted Date : 2008-06-25 21:01:35.0

Avoid using "heavy" SoftReference subgraphs that have the
referent link as an articulation point (i.e. the heavy subgraph
is not otherwise strongly reachable).

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.
Posted Date : 2008-04-04 17:59:12.0

Customer has tested the preliminary fix and is satisfied with the
performance. The fix will be inegrated after due review and testing.
Posted Date : 2008-06-25 21:01:36.0

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
Posted Date : 2008-11-17 19:36:48.0

http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/c96030fff130
Posted Date : 2008-11-21 03:49:21.0