Re: [JBoss-dev] ThreadPooling in JMX? Its broken

[danch <da...@da...>]

Sacha Labourey wrote:
>>>>The Object pooling question was definately settled on the side of it's
>>>>not worth it, but things like threads and sockets _are_ different in
>>>>that the underlying OS has its own limits and imposes them on us.
>>>
>>>
>>>maybe for sockets, but not for threads: a JVM could have (and
>>
>>JRockit does)
>>
>>>an abstraction layer between OS-threads and JVM-threads and do its own
>>>scheduling.
>>>
>>>
>>
>>
>>Yeah, a JVM could have, and one does. That's hardly enough to let us
>>assume that it's pervasive.
>>
> 
> 
> Sure, but your e-mail did look like you were saying that it is a limit
> imposed by the OS on Java, while it is not.
> 

Sure it is. JRocket just has an abstraction that loosens the limit up 
considerable, but the limit is still there. JRocket is basically doing 
your pooling for you - yeah, it's a different mechanism than pooling but 
the effect is the same: you can program as if you can get a thread 
anytime you want, even though you might have to wait anyway.

To entirely get around the limit, the JVM has to completely take over 
the OS's scheduling role for the java application, which was what green 
threads did. I'd rather trust Linus, Ingo, and their hoard of 
contributors and testers to write a good general scheduling algorythm 
than anybody writing a proprietary VM.

-danch