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

[Thomas Schatzl]

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