RFR (S): 8034948 Back out JDK-6976350 since it does not fix any issue
bengt.rutisson at oracle.com
Mon Feb 17 23:45:36 PST 2014
I agree with reverting this fix since the original patch could not show
improvements and we now experience issues with it.
On 2/14/14 2:03 PM, Thomas Schatzl wrote:
> Hi all,
> can I have reviews for the following change?
> During investigation of JDK-8030849 we found that the change in
> JDK-6976350 does not improve fragmentation during GC because it
> implements something different than suggested in the original CR and
> actually tends to decrease performance with large applications with
> large amount of GC threads.
> The CR contains an evaluation of the situation for the dacapo benchmarks
> (as they are fairly fast to run), coming to the above mentioned
> I could not find a good way to fix the change for JDK-6976350, i.e. to
> implement it according to the suggestion in that CR without starting
> from scratch anyway.
> The suggestion is about remembering almost empty buffers and reuse them
> (not sure only within GCs or across GCs - probably the former - if so,
> it might not solve the issue shown in the figures attached to the CR).
> Also, reverting the change is (imo) a reasonable solution for the
> fragmentation issue(s) are investigated in more detail, which may take
> some time.
> Until then, the extra code also just increases the code base.
> Original thread:
> and here:
> continued here:
> I could not find any performance measurements for this change.
> (This is a clean revert of the change)
> jprt, lots of benchmark
More information about the hotspot-gc-dev