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

[Paul Hohensee]

"It the" -> "It's the"

Paul

On 1/22/12 6:56 AM, Paul Hohensee wrote:
> It the intention that just the CMS background thread (of all the GC 
> threads)
> run at critical priority.  That's because it's the serial bottleneck 
> in CMS.  At
> least, that's what it appears to me to be: pls correct me if I'm wrong.
>
> The Solaris guys tell me that Solaris is indeed robust under having more
> critical threads than there are cores.
>
> I don't know that we need critical thread priority for G1, since we intend
> that everything in G1 be parallel.  If we ever change CMS so that the 
> serial
> parts go parallel, then we wouldn't need critical thread priority for CMS.
>
> Paul
>
> On 1/22/12 12:27 AM, Srinivas Ramakrishna wrote:
>> Hi Paul -- First a couple of high level questions:
>>
>> Is it the intention that just the CMS thread run at critical 
>> priority? In the event that one is running
>> with multiple concurrent threads, is the intention that some subset 
>> of these also run at critical priority
>> or is this narrowly targeted at this time to the case of a single GC 
>> thread? (One related question is whether
>> the Solaris API is robust under abuse by having CT priority applied 
>> to "too many" threads -- have you
>> tested for the case where we run with all Java threads designated at 
>> critical priority.)
>>
>> Obviously, all those comments apply also to G1 for which this work 
>> has not yet been done, but looks
>> like what one would ideally want is 
>> UseCriticalPriorityForConcurrentGC or some such for general flag to
>> cover CMS and G1 equally (with perhaps specific suboptions specific 
>> to each).
>>
>> thanks.
>> -- ramki
>>
>>
>> On Fri, Jan 20, 2012 at 9:13 AM, Paul Hohensee 
>> <paul.hohensee at oracle.com <mailto:paul.hohensee at oracle.com>> wrote:
>>
>>     Webrev here
>>
>>     http://cr.openjdk.java.net/~phh/7091418.00/
>>     <http://cr.openjdk.java.net/%7Ephh/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/20120122/e9014e14/attachment.html