compatibility issue regarding the active processor count

[Volker Simonis]

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

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