java threads context switching

[Ethan]

This is regarding java threads context switching. Is there a special
thread in JVM which is responsible for context switch of user java
threads or does each java thread have a corresponding pthread and the
scheduling is left to the underlying OS's scheduler? TIA.

 

[Mike Schilling]

This is regarding java threads context switching. Is there a special
thread in JVM which is responsible for context switch of user java
threads or does each java thread have a corresponding pthread and the
scheduling is left to the underlying OS's scheduler? TIA.

That's an implementation question and the answer will be different for
different JVMs. Having said that, all the modern JVMs I know of use native
OS threads.

 

[Arne Vajhøj]

This is regarding java threads context switching. Is there a special
thread in JVM which is responsible for context switch of user java
threads or does each java thread have a corresponding pthread and the
scheduling is left to the underlying OS's scheduler? TIA.

Java threads ca be implemented as system threads or green threads.

Systems threads is scheduled by the OS.

Green threads is managed by the JVM. I doubt that it would
use a special thread for that. It can't really do much.

All common JVM's use system threads today.

Arne

 

[Kevin McMurtrie]

That's an implementation question and the answer will be different for
different JVMs. Having said that, all the modern JVMs I know of use native
OS threads.

There's also the "M:N threading model" where a large number of Java
threads are backed by a smaller number of native threads. It offers
performance that's almost as good as native threads but it reduces the
kernel overhead of each thread. The downside is that system calls which
suspend native threads can lead to poor performance and deadlocks.

Older OSes ran this way because their native threads were too costly to
support Java's model of blocking I/O.

 

[Arne Vajhøj]

There's also the "M:N threading model" where a large number of Java
threads are backed by a smaller number of native threads. It offers
performance that's almost as good as native threads but it reduces the
kernel overhead of each thread. The downside is that system calls which
suspend native threads can lead to poor performance and deadlocks.

Older OSes ran this way because their native threads were too costly to
support Java's model of blocking I/O.

I thought it was primarily JRockIt before being acquired by BEA
that used this model and that the purpose was to work with more threads.

Arne

 

[Kevin McMurtrie]

I thought it was primarily JRockIt before being acquired by BEA
that used this model and that the purpose was to work with more threads.

Arne

JVMs share a lot of technology back and forth.

It was to boost threads. Java's blocking I/O doesn't work well with
persistent socket communications like HTTP Keepalive, instant messaging,
IMAP, and streaming multimedia unless threads are dirt cheap. They used
to be extremely expensive on Solaris and Linux.