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

[Paul Hohensee]

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/6ce1bbaa/attachment-0001.html