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

Azeem Jiva azeem.jiva at
Fri Jan 20 10:18:01 PST 2012

Looks good.  Thanks for working on this.

Azeem Jiva

On 01/20/2012 11:13 AM, Paul Hohensee 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 
> 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...

More information about the hotspot-runtime-dev mailing list