Number of Parallel GC Threads

[Tony Printezis]

Martin,

Martin Buchholz wrote:
>
>
> On Sat, Jan 24, 2009 at 14:13, Tony Printezis 
> <Antonios.Printezis at sun.com <mailto:Antonios.Printezis at sun.com>> wrote:
>
>
>     Regarding the CAM agent, you said correctly that they should
>     somehow tune its parameters a bit better. And you are right; I
>     would have reported it as a bug.
>
>
>
> 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.
> In general, JDK engineers think in terms of peak performance
> in benchmark-like settings.  I've been guilty of that myself.
> We should try harder to have reasonable performance without
> unreasonable resource consumption, by default.
> Relatively few apps are in the "take over the machine" category.
> Those few apps should be required to ask for such status via
> a JVM flag.
>
> I like the GC work done in the past few years by Matthew Hertz,
> with an emphasis on finding the right balance for resource use
> (particularly memory) by GC, especially adaptively.
Even if we monitor what's happening in the machine and, say, start 
taking resource away from a JVM because the load of the machine is going 
up, we might get users asking why we're taking away resources from the 
"important" JVM in favor of not so important background processes. So I 
still insist: whatever we do, it will not work in some setting and we'll 
have folks complaining.

Tony

-- 
---------------------------------------------------------------------
| Tony Printezis, Staff Engineer   | Sun Microsystems Inc.          |
|                                  | MS UBUR02-311                  |
| e-mail: tony.printezis at sun.com   | 35 Network Drive               |
| office: +1 781 442 0998 (x20998) | Burlington, MA 01803-2756, USA |
---------------------------------------------------------------------
e-mail client: Thunderbird (Linux)