is it possible to run JVM in a pthread?

[Charles T. Smith]

Does anyone know if it's possible to run a JVM in a pthread?

Are there obstacles to doing that, like requirements for non-thread-safe
api's?

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?

 

[Daniel Pitts]

Does anyone know if it's possible to run a JVM in a pthread?

Are there obstacles to doing that, like requirements for non-thread-safe
api's?

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?

pthreads are POSIX threads, right? What dodes that have to do with
running the JVM?

Modern JVMs can use platform specific (a.k.a native) threads, or green
threads of necessary. "What is the efficiency for a number of
threads?" is a trick question. It depends on a lot of factors,
including number of CPU cores, platform, what the threads are doing,
amount of available memory, etc...

If you really want to know more about concurrent programming, I
recommend the book Java Concurrency In Practice <http://
JavaConcurrencyInPractice.com/> It tells you all you need to know
about thread-safety and the thread safety of common Java API's, as
well as creating your own efficient multi-threaded programs.

Hope this helps,
Daniel.

 

[Eric Sosman]

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?

 

[Charles T. Smith]

Charles T. Smith wrote On 04/26/07 01:57,:

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.


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.


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.