United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-7082553 Interpret Thread.setPriority(Thread.MAX_PRIORITY) to mean FX60 on Solaris 10 and 11
JDK-7082553 : Interpret Thread.setPriority(Thread.MAX_PRIORITY) to mean FX60 on Solaris 10 and 11

Details
Type:
Enhancement
Submit Date:
2011-08-23
Status:
Closed
Updated Date:
2012-03-24
Project Name:
JDK
Resolved Date:
2012-03-24
Component:
hotspot
OS:
solaris
Sub-Component:
runtime
CPU:
unknown,generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
hs22,7u2
Fixed Versions:
hs23 (b12)

Related Reports
Backport:
Backport:
Duplicate:
Relates:
Relates:

Sub Tasks

Description
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.

                                    

Comments
EVALUATION

Ok.
                                     
2012-01-24
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.
                                     
2012-01-24
EVALUATION

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

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

http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/de268c8a8075
                                     
2012-03-22



Hardware and Software, Engineered to Work Together