On Thu, 26 Apr 2007 14:03:00 -0400, Eric Sosman wrote:
> Charles T. Smith wrote On 04/26/07 01:57,:
>> Does anyone know if it's possible to run a JVM in a pthread?
>
> Not quite sure what you mean. If you ask "On a platform
> that provides pthreads, can a multi-pthreaded program start a JVM in one
> of its pthreads?" the answer is "Yes." If you mean "On a platform that
> provides pthreads, is it possible to run the JVM in just one pthread?"
the
> answer is "Probably not." In earlier times there were JVM's that used
> native threads and JVM's that used "green threads," but my impression is
> that most contemporary JVM's -- probably all JVM's that use pthreads at
> all -- will themselves launch multiple pthreads and hence not remain
> confined to just one.
>
> And then, of course, there are platforms where pthreads
> aren't supported or aren't supported well enough for a JVM to use.
>
>> Are there obstacles to doing that, like requirements for
non-thread-safe
>> api's?
>
> I can't think of any a priori reason why a JVM (in the
> abstract, as it were) would require thread-unsafe features. That's not
to
> say that some particular JVM implementation doesn't use something dodgy;
> you'd need to get into the details of that particular JVM.
>
>> How about performance, if you have hundreds of such threads? Has
anyone
>> experience with that? Would it necessarily be less efficient that
>> hundreds of java threads? Or more efficient?
>
> The ability to run a JVM alongside other non-JVM threads
> in a multi-threaded program is one thing, but the ability to run
multiple
> non-interfering JVM's in a single address space is something quite
> different. I have not investigated the possibility, but I would be more
> than a little surprised if you were able to get even two JVM's to run
> independently in a single address space -- not "flabbergasted," but
"more
> than a little surprised." The JVM implementations I know of play all
> manner of underhanded trickery to make things work, and it's quite
> possible that at least some of the sleight-of-RAM would need to be
> single-instance.
>
> As for efficiency -- well, it's hard to say. If the JVM's
> are truly non-interfering they'll load all their core classes
> independently, JIT them independently, build redundant class
hierarchies,
> and so on: At the very least, they'll use more memory than the same
> "business" threads running in a single JVM. Memory may be cheap, but
> cache memory is both expensive and hard to expand, and increasing the
> pressure on caches is one good way to slow down a CPU: bigger working
sets
> usually mean poorer performance. Of course, you'd have the same kind of
> memory bloat -- perhaps worse -- if you ran all those JVM's in
independent
> processes. Running multiple threads inside a single JVM will probably
> make the best use of memory.
>
> Still, I get nervous about "hundreds of threads." It may
> be justifiable in your situation (whatever it is), but such a large
thread
> count is often a sign that the design needs some rearranging. What
> problem are you trying to solve?
Thank you, that was a very informative and entertaining answer. And
complete. I'll give up on my idea. ;)
|
