Robert Watson wrote: > > On Sat, 28 Oct 2006, Julian Elischer wrote: > >> Robert Watson wrote: >>> >>> On Fri, 27 Oct 2006, Julian Elischer wrote: >>> >>>> there is class of problems (e.g. some java programs) that have >>>> THOUSANDS of threads, each representing an active aspect of some >>>> object. How do you put an rlimit on that without either 1/ stopping >>>> the program from working or 2/ allowing thousands of threads to >>>> exist but not screwing other users. >>> >>> Does the JVM actually expose thousands of threads to the OS, or does >>> it actually do its own M:N threading internally based on its >>> execution model? My impression is the latter, exposing threads to the >>> OS only when it needs them to consume kernel or CPU resources. >> >> I don't know the answer to that question, only that there is a class >> of program style that uses this model. > > FYI, last night following comments about the change away "green > threads", I ran some simple tests with the 1.4.2 JVM. It appears that, > at least in my simple test cases, all threads created in the JVM are > exposed to the OS. Typically this appears to be about n+8 to n+9 > threads, where n is the number of threads created by the application > itself, and 8/9 is the number created by the JVM. I assume the variance > of one is likely the garbage collector kicking in every now and then (or > something along those lines). > This is correct. The JVM maps all threads directly into the native threading mechanism provided by the OS. 'Green threads' have been defunct since Java 1.3, and no other magic happens behind the scenes. ScottReceived on Sun Oct 29 2006 - 15:21:31 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:01 UTC