FW: RFR (S): memory handling improvements

[Srinivas Ramakrishna]

OK, as I noted, your change looks fine to me. Thanks for sharing.

I'll do the perf runs that I suggested, at my end, and if the numbers bear
out my suspicion,
will file a CR and patch to get rid of that code (subject to performance
verification etc. by the
HotSpot performance team).

thanks.
-- ramki

On Thu, Dec 13, 2012 at 1:25 AM, Lindenmaier, Goetz <
goetz.lindenmaier at sap.com> wrote:

> Hi ramki,****
>
> ** **
>
> I’m not doing the GC stuff at SAP, so I can not change the GC settings in
> ****
>
> our VM.  I just can tell you that we run productive with this change****
>
> for several years now.  And we decided to do the arena allocation for****
>
> performance reasons.****
>
> ** **
>
> Best regards,****
>
>   Goetz.****
>
> ** **
>
> *From:* Srinivas Ramakrishna [mailto:ysr1729 at gmail.com]
> *Sent:* Mittwoch, 12. Dezember 2012 19:20
> *To:* Lindenmaier, Goetz
> *Cc:* hotspot-dev at openjdk.java.net
>
> *Subject:* Re: FW: RFR (S): memory handling improvements****
>
> ** **
>
> Hi Goetz,
>
>
> You might want to test with -XX:+ParGCWorkQueueOverflowALot (turned into a
> product flag) to artificially induce
> overflow and exercise this code with sufficient frequency to get a
> reasonable number of data points to do a
> perf comparison.
>
> I'll also try and run some figures at this end because I have been doing
> some perf numbers related to
> promotion failure handling at this end, and this has a cross-section of
> interaction with that code.
>
> thanks!
> -- ramki****
>
> On Wed, Dec 12, 2012 at 9:57 AM, Srinivas Ramakrishna <ysr1729 at gmail.com>
> wrote:****
>
> 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
>
>
>
> ****
>
> ** **
>
> ** **
>