Pls review 7091418: FX priority class from Solaris should be available to JVM )M)
Paul Hohensee
paul.hohensee at oracle.com
Mon Jan 23 11:26:42 PST 2012
I've got one review (from a Reviewer), need another (doesn't have to
be a Reviewer).
Thanks,
Paul
On 1/20/12 12:13 PM, Paul Hohensee 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
>
More information about the hotspot-runtime-dev
mailing list