Threading Model 1:1 and Java

X

xu_feng_xu

Hi,
It seems that the Java Virtual Machine uses the 1:1 threading mapping
model. According to the theory of this model, all the threads
management and synchronisation are done in the kernel. In particular,
the switching between threads requires kernel intervention and system
calls, which really surprises me considering the speed and
instantaneous execution of some multithreaded applications that i am
running.

Is Java based application threads switching done in the kernel and
through system calls?
Where can i set in JVM another threading model (many to many, one to
one)?
Is there any free profilers which summarize the applications threads
execution and switching durations?

Many thanks
 
O

Oliver Wong

Hi,
It seems that the Java Virtual Machine uses the 1:1 threading mapping
model.

I believe that the threading model uses varies depending on the
capabilities of the underlying OS. Sun's JVM might use "green threads" (i.e.
emulated threads internally) when the underlying OS has no support for
multithreading at all, for example. Other JVMs may implement threading
differently.

[snipped rest, as I don't know the answers]

- Oliver
 
M

Michel Talon

Oliver Wong said:
I believe that the threading model uses varies depending on the
capabilities of the underlying OS. Sun's JVM might use "green threads" (i.e.
emulated threads internally) when the underlying OS has no support for
multithreading at all, for example. Other JVMs may implement threading
differently.

On my machine (FreeBSD) i have:
tulipe% ldd java (in /usr/local/jdk1.4.2/bin):
java:
libpthread.so.1 => /usr/lib/libpthread.so.1 (0x28079000)
libc.so.5 => /lib/libc.so.5 (0x2809d000)

so java uses the native libpthread, which the OS can redirect to a 1:1
threading library, or to a N:M threading library, or to a pure "green thread"
type library which creates userland threads.
 
C

Casper H.S. Dik

It seems that the Java Virtual Machine uses the 1:1 threading mapping
model. According to the theory of this model, all the threads
management and synchronisation are done in the kernel. In particular,
the switching between threads requires kernel intervention and system
calls, which really surprises me considering the speed and
instantaneous execution of some multithreaded applications that i am
running.

Why do you believe that kernel context switch are slower than
userland context switches (where, if preemptive, the kernel
has to be involved in delivering some form of signal anyway and
all potential gain of userland switching is instanteneously lost)
Is Java based application threads switching done in the kernel and
through system calls?

Depends on the JVM implementation and the OS'es threading
model. E.g., on Solaris there were at least three observable
models over time:

- Java's original greenthreads (userland)
- Java on Solaris native threads (N:M model)
- Java on new Solaris native threads (1:1 model)
Where can i set in JVM another threading model (many to many, one to
one)?

Not.

Casper
 
D

David Hopwood

Casper said:
Why do you believe that kernel context switch are slower than
userland context switches (where, if preemptive, the kernel
has to be involved in delivering some form of signal anyway and
all potential gain of userland switching is instanteneously lost)

Preemptive user-mode threading does not necessarily require use of signals
or interrupts. It can be implemented by adding an explicit preemption check
to (roughly speaking) each basic block of the generated code. Erlang/OTP
and Mozart/Oz use this technique, for example. I don't know whether any
Java implementations do.

This particularly makes sense for language implementations where preemption
must occur at a safe point (using interrupts would still be possible in that
case, but then you would have to be able to roll back to the last or forward
to the next safe point, which is complicated).

In any case, even if context switching is done via the kernel in response to
an interrupt, this can be much faster than it is on, say, Linux or Windows.
It isn't the hardware that is imposing most of the overhead, on most OSes.
 
M

Mikko Rauhala

["Followup-To:" header set to comp.os.linux.development.system.]
It seems that the Java Virtual Machine uses the 1:1 threading mapping
model. According to the theory of this model, all the threads
management and synchronisation are done in the kernel.

On Linux this is most often so and sensible, yes.
In particular, the switching between threads requires kernel intervention
and system calls,

Incorrect, this does not require system calls on a pre-emptively
multitasking kernel. (It does involve a brief visit to kernel mode
and the scheduler, of course, and _may_ also be triggered by system
calls.)
which really surprises me considering the speed and
instantaneous execution of some multithreaded applications that i am
running.

....so there is no performance problem.
 
M

Martin James

Preemptive user-mode threading does not necessarily require use of signals
or interrupts. It can be implemented by adding an explicit preemption check
to (roughly speaking) each basic block of the generated code. Erlang/OTP
and Mozart/Oz use this technique, for example. I don't know whether any
Java implementations do.

This is 'preemption'? IMHO, if code cannot be interrupted, it cannot be
preempted.

The above sounds like calling a scheduler after each 'basic block', ie
polling to see if something has changed, (presumably because of some
operation running on another processor). Doesn't sound all that
efficient to me, especially if the 'basic block' is part of a tight loop <g>



Rgds,
Martin
 
M

Marcin 'Qrczak' Kowalczyk

Followup-To: comp.programming.threads

Martin James said:
The above sounds like calling a scheduler after each 'basic block', ie
polling to see if something has changed, (presumably because of some
operation running on another processor). Doesn't sound all that
efficient to me, especially if the 'basic block' is part of a tight
loop <g>

For code which performs lots of context switches, it is faster.
I've measured.

Moreover the same check can fulfill several roles at once: besides
context switching, checking for stack overflow, and delivering Unix
signals such that it is allowed to use arbitrary operations in a
signal handler.
 
D

David Hopwood

More precisely, Mozart/Oz uses a virtual machine and counts VM instructions.
Erlang/OTP with the HiPE compiler does approximately what I said, when executing
compiled code.
This is 'preemption'?

Yes, of course. As long as a thread cannot starve other threads for an unbounded
time, without any explicit yield operations in the *source* language, that is
preemptive threading.
IMHO, if code cannot be interrupted, it cannot be preempted.

There is no difference in semantics between an interrupt-based implementation
and this technique, so it does not make sense to say that one does preemption
and the other not.
The above sounds like calling a scheduler after each 'basic block', ie
polling to see if something has changed, (presumably because of some
operation running on another processor). Doesn't sound all that
efficient to me, especially if the 'basic block' is part of a tight loop
<g>

Mozart/Oz and Erlang/OTP have among the most efficient and scalable user-level
thread implementations of any language. Of course there is overhead, but intuition
is not a reliable guide to how much overhead. As Marcin says in another follow-up,
you need to measure.
 
M

Michel Talon

David Hopwood said:
More precisely, Mozart/Oz uses a virtual machine and counts VM instructions.

By the way, python does exactly the same thing. If there are several threads,
it switches threads each 100 bytecode instructions by default.
 
D

David Hopwood

Michel said:
By the way, python does exactly the same thing.

CPython, yes.
If there are several threads, it switches threads each 100 bytecode instructions
by default.

100 sounds rather small, from the point of view of maintaining cache locality.
I suspect this has not been tuned. In general, performance does not seem to be
a particularly important goal for CPython (that is, it is much slower than a
Python implementation could be without any language changes).
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,904
Latest member
HealthyVisionsCBDPrice

Latest Threads

Top