Number of Parallel GC Threads

[Y Srinivas Ramakrishna]

> >Good question. As Tony pointed out, there seems to be a useful number 
> of 
> >threads to allocate and so his formulation deviates from linear in 
> cases 
> >where there are a large number of CPUs. In this case I guess I would 
> cap 
> >at the min offered by that value and one determined by memory. I 
> don't 
> >have a good feeling for what that other formula would look like but a 
> 
> >good starting point could be something like 1 for something like 
> every 
> >64mb. The actual value could be adjusted using some observations 
> about 
> >how GC was behaving.
> >  
> >
> 
> So linear with the max size of the heap (e.g., 8 GC threads for a 512m
> max heap)
> up to some cap (e.g., using the 5/8's rule Tony described).
> 
> What do you mean by GC behavior?  And adjusting for it?
> 

Not to answer the question for Kirk, but basically as Tony said
and we all agree, no single function form and coefficients we use
will work well for all applications and all workloads. I am
guessing what Kirk means here is some kind of dynamic learning
and readjustment of the coefficients (or in a model-free case
just using some kind of probing in the vicinity of the current
state (i.e. # gc threads) and based on whether that improved the
performance or not, either move in that direction or back --
basically some kind of reinforcement learning approach towards
finding -- and tracking -- an optimal value dynamically.
If that's what Kirk was getting at, I would expect any such
adjustment to happen slowly and for one to be extremely careful
in large ensembles of such JVMs to keep from getting into
oscillations/instability. I am sure (ok i am guessing)
control theorists have solved this ensemble control problem for simple
(homogeneous) cases, but i fear that it may be difficult to get right at
low cost in the kinds of (non-homogeneous, bursty) situations we would
expect to encounter.

Just some loud thinking ....
-- ramki