compatibility issue regarding the active processor count
Jon.Masamitsu at Sun.COM
Wed Oct 1 08:03:19 PDT 2008
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.
More information about the hotspot-dev