Pls review 7091418: FX priority class from Solaris should be available to JVM )M)
paul.hohensee at oracle.com
Sun Jan 22 05:17:56 PST 2012
"It the" -> "It's the"
On 1/22/12 6:56 AM, Paul Hohensee wrote:
> It the intention that just the CMS background thread (of all the GC
> 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
> parts go parallel, then we wouldn't need critical thread priority for CMS.
> 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).
>> -- 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
>> 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
>> Maps Java MAX_PRIORITY to critical priority.
>> All compiler threads run at critical priority.
>> 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
>> 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)
>> being used.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-runtime-dev