FW: RFR (S): memory handling improvements

[Lindenmaier, Goetz]

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<mailto: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<mailto: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/<http://cr.openjdk.java.net/%7Egoetz/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