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

[Srinivas Ramakrishna]

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>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:+**UseCriticalCompilerThreadPrior**ity
>
> 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/20120121/ef9f0da0/attachment.html