RFR (S): 8034948 Back out JDK-6976350 since it does not fix any issue

[Bengt Rutisson]

Hi Thomas,

Looks good.

I agree with reverting this fix since the original patch could not show 
improvements and we now experience issues with it.

Bengt

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
> conclusions.
>
> 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:
> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2013-January/005719.html
> and:
> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2013-February/005793.html
> and here:
> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2013-May/007167.html
> continued here:
> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2013-June/007423.html
>
> I could not find any performance measurements for this change.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8034948
>
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8034948/webrev/
> (This is a clean revert of the change)
>
> Testing:
> jprt, lots of benchmark
>
> Thanks,
>    Thomas
>