compatibility issue regarding the active processor count

[Jon Masamitsu]

On 10/01/08 07:43, Volker Simonis wrote:
> os::is_server_class_machine() depends on active_processor_count()
> although it is not clear if a server class machine (per definition >=
> 2CPU's) with fewer active CPU's should still act as a server class
> machine or not...

I think it would be a definite improvement if is_server_class_machine()
saw the fewer cpus and  returned false (assuming the new and improved
active_processor_count() return 1).

> 
> On 10/1/08, Jon Masamitsu <Jon.Masamitsu at sun.com> wrote:
>> I would vote to have the new value be the default.  That's
>>  based on the principle of "least surprise".  People who
>>  need to think about such things probably already believe
>>  they are getting the new value.
>>
>>  The number of default GC thread for the parallel collector
>>  (UseParallelGC) was changed in HSX 12 (hotspot express) to
>>  be consistent with the number of default threads used with
>>  UseParNewGC/cms (CR 6362677).  So there has been a change
>>  recently. I'll probably being hearing some complaints
>>  about my change (hopefully not many), so I can include
>>  the new calculation of the active number of processors
>>  too, if relevant, in my explanations.  Not sure what
>>  else beside GC will be affected by the new calculation
>>  of active processors.
>>
>>
>>  On 09/30/08 17:11, Xiaobin Lu wrote:
>>
>>> Hi folks,
>>>
>>> I need your opinion about what we should do to solve the compatibility
>> issue regarding the active processor count. Basically, the problem is on
>> Solaris, if you create a processor set and then launch java process without
>> binding to that processor set, the number of available processors to that
>> java process is the total number of the online processors minus the number
>> of processors in the processor set you created. Currently, we just report
>> the total number of the online processors as the active processor count
>> which is wrong. This makes the parallel garbage collector to behave in the
>> wrong way (see bug 6749430 for details) and we need to fix it per request
>> from CBOE.
>>> There may be a compatibility issue after we correct this wrong behavior
>> when someone has already depended on this wrong return, which we think it
>> might be rare. We definitely need to invent a new flag in order to address
>> this and the question is whether we should keep the current behavior as
>> default or not. Personally, I feel we should have that flag to fall back to
>> the current wrong behavior, but I might be wrong.
>>> Thanks so much in advance for your opinion.
>>>
>>> -Xiaobin
>>>
>>>
>>>
>>>
>>>