Number of Parallel GC Threads

[kirk]

Y Srinivas Ramakrishna wrote:
>   
>>> 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 ....
>   
I didn't know I was so clever ;-)

I was thinking about this a bit but unless you understand what is going 
on with the competing JVMs.... I think that could be a bigger influence. 
At any rate, I'd consider this a gross optimiztion. Trying to fine tune 
it may not make sense.

Regards,
Kirk