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

[Srinivas Ramakrishna]

Thanks Paul; yes, what you say makes sense about the serial parts becoming a
possible bottleneck that might require this kind of intervention. So I am
good with
your current change. I am curious if there are any performance numbers that
may be available for sharing here (i understand that may not be possible,
perhaps because this is still somewhat of an experiment in progress).

Thanks for the work!
-- ramki


On Sun, Jan 22, 2012 at 3:56 AM, Paul Hohensee <paul.hohensee at oracle.com>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>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/20120122/7884f9d7/attachment.html