java threads context switching
in [Java Programming]
|
From: Kevin McMurtrie on 1 Jul 2010 01:43 In article <4c2bdd51$0$281$14726298(a)news.sunsite.dk>, Arne Vajh�j <arne(a)vajhoej.dk> wrote: > On 30-06-2010 00:36, Kevin McMurtrie wrote: > > In article<i0e6df$lom$1(a)news.eternal-september.org>, > > "Mike Schilling"<mscottschilling(a)hotmail.com> wrote: > >> "Ethan"<sam_cit(a)yahoo.co.in> wrote in message > >> news:e04adb13-ae97-4182-97bb-e41a2fc952a6(a)z34g2000pro.googlegroups.com... > >>> 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. > > > > 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 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. -- I won't see Google Groups replies because I must filter them as spam |