United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4813310 : Map Thread priorities to system thread/process priorities

Details
Type:
Enhancement
Submit Date:
2003-02-05
Status:
Closed
Updated Date:
2012-10-13
Project Name:
JDK
Resolved Date:
2005-10-13
Component:
hotspot
OS:
linux
Sub-Component:
runtime
CPU:
x86
Priority:
P3
Resolution:
Fixed
Affected Versions:
1.4.1,5.0
Fixed Versions:

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

Sub Tasks

Description
I inspected several JVMs for their background threading support:
                       
Linux Sun JVM 1.4.1             no
Linux Sun JVM 1.3.1             no
Linux Blackdown JVM 1.4.1 beta  no
Linux Bea JVM 1.4               --  
Linux IBM JVM 1.4               no
Solaris Sun JVM 1.4.1           no
MacOS-X Apple JVM 1.4.1-a7      yes
Windows Sun JVM 1.4.1           yes

no - behaves like simple round-robin scheduler (ignoring priorities).

A sample microbenchmark attached.
###@###.### 10/14/04 14:28 GMT

                                    

Comments
EVALUATION

------------------

Updated: January 30, 2007

To clarify the "fix" here, all that is done is to adjust the "niceness" of the kernel thread that is presumed to be bound to the Java thread by calling setpriority(). This does not provide strict priority preemptive scheduling as it is still done within the SCHED_OTHER scheduling policy by default. This means that lower "priority" threads will gradually increase in priority (priority ageing) as each timeslice elapses. Hence all threads will get a chance to run.

The Hotspot VM will not work reliably under strict priority preemptive scheduling - for that you need a real-time Java implementation such as Sun's Java Real-Time System (Java RTS): http://java.sun.com/javase/technologies/realtime.jsp

Also note that Thread.yield itself is not specified to be priority-based - there is no requirement that a high priority thread returns immediately from yield if only lower priority threads are runnable. In contrast OS "yield" operations are often defined in terms of priority (eg. placing the current thread at the tail of the queue for its priority level), such as the linux sched_yield method which is actually used for Thread.yield on linux. However sched_yield's behaviour is defined in terms of the static priority of the thread (really process) and that value is always zero under SCHED_OTHER, so regardless of the nice level, sched_yield will relinquish the processor if another thread is ready.
                                     
2007-01-30
EVALUATION

----------------------------------
Fixed by using setpriority() in root mode. To use thread priority on Linux, the
application needs to run as root *and* -XX:ThreadPriorityPolicy=1 is set on the
command line, otherwise thread priorities are ignored.
                                     
2005-10-05
EVALUATION

In the last two weeks, I've been testing Java threads with SCHED_RR policy.
Unlike SHCED_OTHER, SCHED_RR allows static priority (1-99) and it puts
the thread in real-time scheduling class. SCHED_RR requires root privilege.
The idea is, if SCHED_RR works OK, at least we could support Java priority
if the application is run by privileged user.

However, the bad news is that SCHED_RR does not work. For small apps, it
seems fine, but for heavily multi-threaded application (e.g. volano), it
hangs easily. This happened on various Linux distributions and multiple
machines, with both old and the O(1) scheduler. It's not a hang in the 
application, but the entire system locked up and required a power cycle.
The data that I collected from the few successful runs aren't promising
either. Comparing to SCHED_OTHER, the same benchmark is slower with
SCHED_RR, sometimes by a large margin. See comments for data.

My conclusion from the tests is that SCHED_RR policy is not for multi-threaded
application like java.

The only remaining "choice" is setpriority() for privileged users. But I'm
not yet convinced it's worthwhile.
                                     
2005-09-28
WORK AROUND

Yielding see 4799163

###@###.### 2003-03-24
                                     
2003-03-24
EVALUATION

It is intentional that the JLS provides little in the way of guarantees regarding the behavior of thread priorities.  It is not feasible to provide guarantees that apply across platforms with markedly different underlying threading models.  

    As a consequence, developers are well advised to limit their use of thread priorities to fine-tuning the responsiveness of a working application.  This is discussed in detail in Joshua Bloch's "Effective Java Programming Language Guide", Item 51 ("Don't depend on the thread scheduler").

   That said, it is possible that the Java platform threading implementation on Linux doesn't take full advantage of the underlying threading implementation.  I leave it to the VM group to make this determination.

###@###.### 2003-02-11

----------------------------------------------

It's well documented that the default Linux scheduling policy SCHED_OTHER
(btw, this is the only scheduling policy that can be used by non-priviledged
users) uses static priority 0 for all threads/processes. Every thread has
the same priority. However, kernel scheduler does try to give interactive 
tasks a higher priority than CPU hogs, but that's not something can be
controlled by user apps.

The only way around this is to exploit the fact that threads are indeed
processes and use process niceness to simulate thread priorities. But doing
so inside JVM is inappropriate because it's based on a broken model (Linux
pthread itself is moving away from the non-POSIX thread-is-process model) 
and it doesn't really solve the problem (non-root user can only lower 
priority but not the opposite).

This RFE will not be fixed until Linux scheduler can support true thread
priorities.

###@###.### 2003-02-18
                                     
2003-02-18



Hardware and Software, Engineered to Work Together