views:

187

answers:

4

Hello !

I am really curious about how does the JVM work with threads ! In my searches in internet, I found some material about RTSJ, but I don't know if it's the right directions for my answers. I also found this topic in sun's forums, http://forums.sun.com/thread.jspa?forumID=513&threadID=472453, but that's not satisfatory.

Can someone give me some directions, material, articles or suggestion about the JVM scheduling algorithm ?

I am also looking for information about the default configurations of Java threads in the scheduler, like 'how long does it take for every thread' in case of time-slicing. And this stuff.

I would appreciate any help !

Thank you !

A: 

It doesn't. The JVM uses operating system native threads, so the OS does the scheduling, not the JVM.

Chris Dolan
Some JVMs manage their own threads. The early Sun JVM did this. Some modern small embedded JVMs do this as well.
Will Hartung
@Will Hartung: true, http://en.wikipedia.org/wiki/Green_threads says the Hotspot JVM has used native threads since 1.2 days
Chris Dolan
@Chris: no, the article says that the 1.1 JVM used them on Solaris, and I remember them being used by the Linux JVM when it was still called Blackdown, but I'm pretty sure that Hotspot (which became part of the JVM only in 1.3) never used green threads.
Michael Borgwardt
"Green threads" are a bit pointless on machines with more than one hardware thread. However there is a scheme (was used by JRockit, IIRC, not sure whether it still does), where it uses a number of native threads but they are not directly linked to Java threads. Might have been a particular optimisation for 32-bit systems (remember them?).
Tom Hawtin - tackline
+5  A: 

There is no single Java Virtual Machine; JVM is a specification, and there are multiple implementations of it, including the OpenJDK version and the Sun version of it, among others. I don't know for certain, but I would guess that any reasonable JVM would simply use the underlying threading mechanism provided by the OS, which would imply POSIX Threads (pthreads) on UNIX (Mac OS X, Linux, etc.) and would imply WIN32 threads on Windows. Typically, those systems use a round-robin strategy by default.

Michael Aaron Safyan
There is the Java Virtual Machine Specification (http://java.sun.com/docs/books/jvms/second_edition/html/VMSpecTOC.doc.html) or "JVM spec". But when someone talks about "a JVM" or "the JVM", then they usually mean an implementaton of the spec and not the spec itself.
Joachim Sauer
@Sauer, yes, the term "the JVM" implies a single JVM, and while this makes sense in the context of a discussion about a particular JVM (e.g. the Sun HotSpot JVM), it does not make any sense without establishing which particular JVM is being discussed.
Michael Aaron Safyan
@Michael: Personally I often find myself saying things like "the JVM will load the class ..." or "the JVM will make sure, that ..." which *definitely* refers to an implementation, although it's not relevant to the discussion which concrete implementation I'm talking about. On the other hand, when I'm talking specifically about the specification, then that should be noted "The JVM spec specifies, that ..." or something like that.
Joachim Sauer
A: 

Here is a awesome document you can have a look. http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html

giri
It's an awesome document, but it doesn't talk about thread scheduling.
Joachim Sauer
+2  A: 

A while ago I wrote some articles on thread scheduling from the point of view of Java. However, on mainstream platforms, threading behaviour essentially depends on underlying OS threading.

Have a look in particular at my page on what is Java thread priority, which explains how Java's priority levels map to underlying OS threading priorities, and how in practice this makes threads of different priorities behave on Linux vs Windows. A major difference discussed is that under Linux there's more of a relationship between thread priority and the proportion of CPU allocated to a thread, whereas under Windows this isn't directly the case (see the graphs).

Neil Coffey