 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / October 2006Threading Model 1:1 and Java
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 > 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 > > Hi, > > It seems that the Java Virtual Machine uses the 1:1 threading mapping [quoted text clipped - 5 lines] > 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.  SignatureMichel TALON >It seems that the Java Virtual Machine uses the 1:1 threading mapping >model. According to the theory of this model, all the threads [quoted text clipped - 3 lines] >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 SignatureExpressed in this posting are my opinions. They are in no way related to opinions held by my employer, Sun Microsystems. Statements on Sun products included here are not gospel and may be fiction rather than truth. >>It seems that the Java Virtual Machine uses the 1:1 threading mapping >>model. According to the theory of this model, all the threads [quoted text clipped - 8 lines] > 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. SignatureDavid Hopwood <david.nospam.hopwood@blueyonder.co.uk> > 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 Followup-To: comp.programming.threads > 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. Signature__("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/ >> 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. 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. >> I don't know whether any Java implementations do. > > 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. SignatureDavid Hopwood <david.nospam.hopwood@blueyonder.co.uk> > >> 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. > > 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. SignatureMichel TALON >>>>Preemptive user-mode threading does not necessarily require use of >>>>signals or interrupts. It can be implemented by adding an explicit preemption [quoted text clipped - 4 lines] > > 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). SignatureDavid Hopwood <david.nospam.hopwood@blueyonder.co.uk> ["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. SignatureMikko Rauhala - mjr@iki.fi - <URL:http://www.iki.fi/mjr/> Transhumanist - WTA member - <URL:http://www.transhumanism.org/> Singularitarian - SIAI supporter - <URL:http://www.singinst.org/> Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.