• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Number of JVMs in a CPU

 
Deepak Kumar
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
How many JVMs will be there in a CPU when i start(run) more than one main process?
Can any one please clear me on the same. and how to spawn JVM.

Thanks in Advance.....
 
Ernest Friedman-Hill
author and iconoclast
Marshal
Pie
Posts: 24208
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

Welcome to JavaRanch!

In your haste to come in and ask a question, you seem to have missed reading our policy on display names, which quite clearly states that you must use a real (sounding) first and last name for your display name -- a single name is not acceptable. You can fix your display name here. Thanks for your cooperation!

As to your question: the program java.exe (or whatever it's called on your OS) represents a single JVM. Each time you launch java.exe, you get another JVM.
[ August 03, 2005: Message edited by: Ernest Friedman-Hill ]
 
Deepak Kumar
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ernest ,

Thanks for your replay..
 
Norm Radder
Ranch Hand
Posts: 728
4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A slightly related topic. I have a number of Java programs that I use in a round robin manner while doing a project. Instead of having each of them use their own JVM (slooooow startup on my system), I wrote a Java program that will start and run a program in the same JVM. It has a SecurityManager to trap System.exit() and a classloader so each program can have its own classpath.

It mostly works but of course, there have been few problems with it. The main one being how to stop threads the programs start. The only way I've found is by program switches in each program that are set before doing a System.exit().

Can anyone comment or recommend other things I should consider?

Thanks,
Norm
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You could start the new program in a thread of a new thread group. As long as the program doesn't create its own thread groups, all of its threads will be started in that group, then.
 
Norm Radder
Ranch Hand
Posts: 728
4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What advantage is there to having the threads in the same group?
The problem is: How to stop the threads? The methods have been deprecated!
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Norm Radder:
What advantage is there to having the threads in the same group?
The problem is: How to stop the threads? The methods have been deprecated!


The stop method is deprecated because it can leave a program in an inconsistent state. As you want to terminate the whole program anyway, that's probably not a problem, is it?
 
Norm Radder
Ranch Hand
Posts: 728
4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Let me explain again. I have a program (JavaEx) that starts other programs and has them run in the SAME JVM as JavaEx. The problem I mentioned was when I exited the one of the other programs, if it had threads running, the threads kept running. I don't want to exit the JavaEx program. There might be other programs running in its JVM or I might want to start new programs using JavaEx.
So with this design, what use are ThreadGroups for the started programs?
How can they help stop threads?
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Norm Radder:
Let me explain again. I have a program (JavaEx) that starts other programs and has them run in the SAME JVM as JavaEx. The problem I mentioned was when I exited the one of the other programs, if it had threads running, the threads kept running. I don't want to exit the JavaEx program. There might be other programs running in its JVM or I might want to start new programs using JavaEx.
So with this design, what use are ThreadGroups for the started programs?
How can they help stop threads?


ThreadGroup has a stop method that stops all threads in the group.
 
Norm Radder
Ranch Hand
Posts: 728
4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Aren't you the same person that two posts back said stop() was deprecated?
It is for both Thread and ThreadGroups.

Which makes the last 4 posts useless. Let's backup and try again.
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
They're not useless. It's still possible to use deprecated methods, if you understand the associated problems and don't have a better solution. I would say that the preferred solution would be to make sure the other programs are written to handle an interrupt() gracefully and terminate their operations in a safe manner, as soon as possible. However if you don't have control over how those other programs are written, this simply may not be possible, and you may be forced to use stop() even though it's deprecated. Using stop() will mean that any data that was being accessed by those other programs may be in some inconsistent state after stop() is called. However the rest of the JVM is fine. If you can sufficiently limit the amount of data that's shared between these programs, you should be fine.

Probably the biggest risk of non-obvious shared data is mutable static fields. One thread could be modifying data which is accessible to the whole JVM. If that thread is stopped, the shared data is suspect. You can (hopefully) protect yourself from this by using separate class loaders for each "program" - so that when program A needs to use class Foo, and program B also needs class Foo, they actually get two different versions of Foo. So when A is stopped and A's version of Foo is corrupted, it doesn't matter, since B isn't using that version of Foo. This is basically what app servers do, so that different applications can run in a single JVM without stepping on each other's toes. And you might want to consider using an existing app server to do whatever you're trying to do, rather than roll your own. Good luck...
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What Jim said.

And as an aside, it was *you* who said that stop is deprecated, and me who tried to explain that in your case it probably doesn't matter. Claiming that my effort was useless makes me kinda reluctant to help further...
 
Norm Radder
Ranch Hand
Posts: 728
4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sorry if I stepped on any toes.
I thought that deprecated meant that it could be removed from the language.
I should live so long....

The app server sounds interesting. Am I reinventing the wheel?
Where could I get a copy?

One of the reasons I created this program was to save on JVM load time. On my 333Mhz system, the JVM takes seconds to start. If I'm using one tool and want to start another, having this program running shortens the startup time a lot.
 
Norm Radder
Ranch Hand
Posts: 728
4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Whoops! Unexpected results. May need new design!
I added code to place the started program in a ThreadGroup and then code in the Security to show what ThreadGroup the caller to System.exit() was in.
Guess which one it was?
AWT - In my programs I have a windowListener for closing that calls System.exit(), so its no suprise really.

The question is how do I find the ThreadGroup associated with that System.exit() call. There can be more than one copy of the same program running so I can't use the classname from the stack.
I didn't want to have to reprogram every program that I add to this system, but now see no other way.
Any other ideas. Or at least ideas that have minimum impact on existing code.
 
Consider Paul's rocket mass heater.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic