FW: RFR (S): memory handling improvements

Srinivas Ramakrishna ysr1729 at gmail.com
Wed Dec 12 10:20:14 PST 2012


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
>>
>>
>>
>>
>>
>


More information about the hotspot-dev mailing list