Number of Parallel GC Threads

[Nicolas Michael]

Hi Tony,

Tony Printezis schrieb:

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

I absolutely agree with you: Such "dynamic" optimizations have a high 
potential of going into the wrong direction. And what I dislike even 
more about them: They make system behavior very difficult to predict. 
When you look at your system, you may find everything working just fine. 
Then you probably have one application going nuts, and suddenly all 
JVM's start adapting their resources. Or you start another JVM (let's 
say, the Sun Studio Analyzer), and suddenly your work-load JVM's reduce 
their GC threads... I wouldn't want to be the poor guy who would have to 
analyze after such a situation what has happened when a customer is 
complaining about a weird system behavior. Or make performance 
predictions when I don't know which strange situations may make the JVM 
to rethink its settings. I'm just imagining a situation where the server 
hits overload because of a burst of incoming requests, and the JVM's 
think "Oh, there's so much load on the server, let's reduce our resource 
usage and kill some of them gc threads." -- and afterwards suffer from 
longer gc pauses which makes it even more difficult for them to keep up 
with the load.

On the other hand, there may be some better default settings that the 
JVM could derive from some "static" parameters. I believe Martin is 
right that most apps are not in the "take over the machine" category, 
especially when it comes to really large servers. Are there really 
people who run just one JVM instance on a 64/128/256 cpu CMT server for 
example?? And even if they do, they certainly have lots of mutator 
threads (otherwise it wouldn't make sense to run just one JVM on such a 
server), so they would have lots of object creation and would need quite 
a large heap for a reasonable operation.

Those "agent" processes that I was referring to (CAM just being one of 
them) are rather "small" processes (128m heap in case of the CAM agent). 
And I would assume that most of those "performance-uncritical background 
processes" that you might run on large servers come with small heaps (I 
sure hope -- I don't want them to use up my memory!). And even 
performance-hungry apps with small heaps don't need too many gc threads 
(and if they are really performance-hungry *and* have small heaps *and* 
run on very large servers, they are likely to be deployed in more than 
one instance... if they run single-instance, they should need *large* 
heaps). So it should be possible for the JVM to come up with an upper 
limit for the number of gc threads depending on the server size (cpus, 
memory) and max heap size of the application. Probably there are even 
other or better indications that I currently don't think of. And 
probably there's more than just the number of gc threads that could be 
sized that way...?


That's all for now, and sorry for my long mails... ;-)

Thanks,
Nick.