JDK-7082553 : Interpret Thread.setPriority(Thread.MAX_PRIORITY) to mean FX60 on Solaris 10 and 11
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: hs22,7u2
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris
  • CPU: generic,unknown
  • Submitted: 2011-08-23
  • Updated: 2013-11-01
  • Resolved: 2012-03-24
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7 JDK 8 Other
7u4Fixed 8Fixed hs23Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
See Comments.
A SPARC T4 processor can run in either multi- or single-thread mode.  In multi-thread
mode, core resources are shared by 8 threads, but in single-thread mode all core
resources are dedicated to a single thread, resulting in much higher performance
for that single thread relative to running it in multi-thread mode.

The default Solaris time-sharing scheduler is biased toward maximum use of hardware
resources by as many LWPs as possible, which means that multi-thread mode is the
default.  To use T4's single-thread mode effectively, the scheduler must know which
LWP(s) should run in that mode.  Solaris 10u10 and 11 will do their best to
give LWPs running at priority 60 in the FX scheduling class exclusive use of
a T4 core, thus running the LWP in single-thread mode.

We'd like Java applications that require fast per-thread response time to run in
the FX60 scheduling class.  One way to do so is to use Thread.setPriority(Thread.
MAX_PRIORITY) as a directive to use FX60 for that thread when running on a T4 and
S10u10/S11.  This is a change from current practice, which maps the available Java
thread priorities evenly across the 60 (0-59) Solaris time sharing priorities.
We don't expect that to be a problem, however, since the proposed change will
apply only to T4, which is new hardware.  Note that this CR uses "unknown" for
the Hardware field: T4 is not yet available as a Hardware option in bugster.

EVALUATION http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/de268c8a8075

EVALUATION http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/de268c8a8075

EVALUATION http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/de268c8a8075

SUGGESTED FIX Define 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. Add 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. The Solaris implementation can only change priorities within the process scheduling class. It doesn't change scheduling classes on a per-thread basis. Add that capability (to set_lwp_priority) and use it for the critical thread work. CriticalPriority should work the same way on Solaris regardless of the value of -XX:ThreadPriorityPolicy. The priority value specified by CompilerThreadPriority should override UseCriticalCompilerThreadPriority. That way, users of CompilerThreadPriority will see the current behavior.