Number of Parallel GC Threads

[Martin Buchholz]

On Mon, Jan 26, 2009 at 07:12, Tony Printezis <Antonios.Printezis at sun.com>wrote:

>
>> It's hard to fault an application for using the defaults. Tuning should
>> only be necessary to achieve top performance,
>> not to achieve reasonable performance. If an application ends up not being
>> a good citizen as a result of decisions made by  the JVM, that's  a bug in
>> the JVM.
>>
> I don't think so. We need a reasonable balance between giving reasonable
> performance and being a good citizen. Once upon the time we tried to do what
> you are suggesting, i.e., trying to be a good citizen by default and
> requiring tuning for performance. And that was not a big success, as users
> kept complaining why our settings were too conservative, why they kept
> getting OOMs given the small heap, why performance was not the best, etc.
> So, we've been there, done that, it didn't work.


Being a good citizen does not include failing due to OOME.

Being a good citizen, to me, means things like:
- gc'ing when the heap has grown from previous collection by a factor of
2-3,
  instead of a factor of 20
- using 5 concurrent gc threads instead of 100

In general, don't double resource consumption to get an additional 1%
performance,
by default.

I agree with Tony that customers are going to have
a harder time managing applications the more dynamic
that resource management becomes.
But I think this comes with the territory.
It is much harder to do performance measurement
of Java code in general, because the execution model
with multiple runtimes has become so complex and dynamic.
But that's called progress.  We should be aiming all parts of
our runtimes to be more dynamic in the same way.
Lots of difficult work remaining to be done by VM engineers.

Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20090126/c02ef808/attachment.htm>