Pls review 7091418: FX priority class from Solaris should be available to JVM

[Paul Hohensee]

Unfortunately, however, you don't have an openjdk name, so I can't list
you as a reviewer. :(

Paul

On 1/23/12 3:59 PM, Paul Hohensee wrote:
> Thanks!
>
> paul
>
> On 1/23/12 3:46 PM, charlie hunt wrote:
>>  Looks good.
>>
>> hths,
>>
>> charlie ...
>>
>> On 01/23/12 01:26 PM, Paul Hohensee wrote:
>>> I've got one review (from a Reviewer), need another (doesn't have to
>>> be a Reviewer).
>>>
>>> Thanks,
>>>
>>> Paul
>>>
>>> On 1/20/12 12:13 PM, Paul Hohensee wrote:
>>>> Webrev here
>>>>
>>>> http://cr.openjdk.java.net/~phh/7091418.00/
>>>>
>>>> This change defines a new Java pseudo-priority called 
>>>> CriticalPriority, just
>>>> above MaxPriority.  Compiler threads, the CMS background thread, and
>>>> Java threads can have the os equivalent of this priority.  On 
>>>> Solaris, this is
>>>> the FX/60 scheduling class/priority.  On other platforms, it's the 
>>>> same
>>>> as MaxPriority's os priority.
>>>>
>>>> There are 3 new command line switches, all gated by 
>>>> UseExperimentalVMOptions.
>>>>
>>>> -XX:+UseCriticalJavaThreadPriority
>>>>
>>>> Maps Java MAX_PRIORITY to critical priority.
>>>>
>>>> -XX:+UseCriticalCompilerThreadPriority
>>>>
>>>> All compiler threads run at critical priority.
>>>>
>>>> -XX:+UseCriticalCMSThreadPriority
>>>>
>>>> The CMS background thread runs at critical priority.
>>>>
>>>> On Solaris, one must in addition use -XX:+UseThreadPriorities to 
>>>> use native
>>>> priorities at all.  Otherwise, Hotspot just accepts whatever 
>>>> Solaris decides.
>>>>
>>>> Before this change, the Solaris implementation could only change 
>>>> priorities
>>>> within the process scheduling class.  It didn't change scheduling 
>>>> classes on
>>>> a per-thread basis.  I added that capability and used it for the 
>>>> critical thread
>>>> work.  I also fixed a bug where we were using thr_setprio() to save 
>>>> the
>>>> original native priority during thread creation and reading it back 
>>>> when
>>>> the thread started via thr_getprio().  Since thr_setprio() can 
>>>> change the
>>>> user-supplied priority, this resulted in an unintended (lower) 
>>>> priority
>>>> being used.
>>>>
>>>> Thanks,
>>>>
>>>> Paul
>>>>
>>
>>