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

[Paul Hohensee]

Thanks for the review,

Paul

On 1/20/12 1:18 PM, Azeem Jiva wrote:
> Looks good.  Thanks for working on this.
> Azeem Jiva
> @javawithjiva
>
> On 01/20/2012 11:13 AM, 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
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20120120/158dd2f9/attachment.html