Re: is it possible to run JVM in a pthread?
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?
--
Eric.Sosman@sun.com