FW: RFR (S): memory handling improvements

[Srinivas Ramakrishna]

Goetz. shouldn't we be using ParGCUseLocalOverflow true by default, and get
rid of the global linked list
code? I was surprised to find that it's off by default. Have you tested
your code with +/- ParGCUseLocalOverflow
to see how much of a difference it makes (with and without yr change to use
a resource allocated field
to link the overflow objects?) It seems as though if ParGCUseLocalOverflow
performs better, which i think it
will, we should just use that and get rid of the more complicated code
(memory is cheap, maintaining complicated
code is expensive, especially if that complicated code is also slow!)

Both your changes look good otherwise (i.e. from a correctness point of
view).

thanks!
-- ramki




On Wed, Dec 12, 2012 at 8:28 AM, Lindenmaier, Goetz <
goetz.lindenmaier at sap.com> wrote:

> Hi,
>
>
> = > Sorry, now I fixed the link to the webrev.
>
> I found two fixes for memory handling in our (SAP) hotspot code and want
> to share this with you:
> http://cr.openjdk.java.net/~goetz/webrevs/webrev-mem/
>
> In classLoader.cpp there is a memory leak, easy to be fixed.
>
> In parNewGeneration we allocate the overflow list elements
> on an arena. This is faster to allocate and no free is necessary.  It
> performed
> better with our VM than malloc/free.
>
> I propose to change openJDK accordingly.
>
> Best regards,
>   Goetz Lindenmaier
>
>
>
>
>