Threading Model 1:1 and Java

Discussion in 'Java' started by xu_feng_xu@yahoo.com, Oct 5, 2006.

  1. Guest

    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
     
    , Oct 5, 2006
    #1
    1. Advertising

  2. Oliver Wong Guest

    <> wrote in message
    news:...
    > 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
     
    Oliver Wong, Oct 5, 2006
    #2
    1. Advertising

  3. Michel Talon Guest

    Oliver Wong <> wrote:
    >
    > <> wrote in message
    > news:...
    > > 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.


    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.



    --

    Michel TALON
     
    Michel Talon, Oct 5, 2006
    #3
  4. writes:

    >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
    --
    Expressed 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.
     
    Casper H.S. Dik, Oct 5, 2006
    #4
  5. Casper H.S. Dik wrote:
    > writes:
    >
    >>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)


    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.

    --
    David Hopwood <>
     
    David Hopwood, Oct 6, 2006
    #5
  6. ["Followup-To:" header set to comp.os.linux.development.system.]
    On 5 Oct 2006 10:19:13 -0700, <> wrote:
    > 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.

    --
    Mikko Rauhala - - <URL:http://www.iki.fi/mjr/>
    Transhumanist - WTA member - <URL:http://www.transhumanism.org/>
    Singularitarian - SIAI supporter - <URL:http://www.singinst.org/>
     
    Mikko Rauhala, Oct 6, 2006
    #6
  7. Martin James Guest

    >
    > 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
     
    Martin James, Oct 6, 2006
    #7
  8. Followup-To: comp.programming.threads

    Martin James <> writes:

    > 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.

    --
    __("< Marcin Kowalczyk
    \__/
    ^^ http://qrnik.knm.org.pl/~qrczak/
     
    Marcin 'Qrczak' Kowalczyk, Oct 6, 2006
    #8
  9. Martin James wrote:
    > David Hopwood wrote:
    >> 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.

    --
    David Hopwood <>
     
    David Hopwood, Oct 7, 2006
    #9
  10. Michel Talon Guest

    David Hopwood <> wrote:
    > Martin James wrote:
    > > David Hopwood wrote:
    > >> 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.


    --

    Michel TALON
     
    Michel Talon, Oct 7, 2006
    #10
  11. Michel Talon wrote:
    > David Hopwood <> wrote:
    >>Martin James wrote:
    >>>David Hopwood wrote:
    >>>
    >>>>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.


    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).

    --
    David Hopwood <>
     
    David Hopwood, Oct 7, 2006
    #11
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    2
    Views:
    457
    =?ISO-8859-1?Q?Arne_Vajh=F8j?=
    Oct 3, 2006
  2. Replies:
    1
    Views:
    515
    Andreas Wollschlaeger
    Oct 6, 2006
  3. Kevin  Erickson
    Replies:
    2
    Views:
    1,144
    Mike Schilling
    Feb 27, 2007
  4. Dave

    Threading Model

    Dave, Aug 4, 2003, in forum: ASP General
    Replies:
    1
    Views:
    146
    vivek
    Aug 4, 2003
  5. Replies:
    7
    Views:
    163
    Bob Hutchison
    Jan 11, 2006
Loading...

Share This Page