aspose file tools*
The moose likes Performance and the fly likes Number of JVMs in a CPU Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » Performance
Bookmark "Number of JVMs in a CPU" Watch "Number of JVMs in a CPU" New topic
Author

Number of JVMs in a CPU

Deepak Kumar
Greenhorn

Joined: Jul 21, 2005
Posts: 15
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

Joined: Jul 08, 2003
Posts: 24187
    
  34

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 ]

[Jess in Action][AskingGoodQuestions]
Deepak Kumar
Greenhorn

Joined: Jul 21, 2005
Posts: 15
Hi Ernest ,

Thanks for your replay..
Norm Radder
Ranch Hand

Joined: Aug 10, 2005
Posts: 687
    
    1
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

Joined: Jul 11, 2001
Posts: 14112
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.


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Norm Radder
Ranch Hand

Joined: Aug 10, 2005
Posts: 687
    
    1
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

Joined: Jul 11, 2001
Posts: 14112
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

Joined: Aug 10, 2005
Posts: 687
    
    1
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

Joined: Jul 11, 2001
Posts: 14112
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

Joined: Aug 10, 2005
Posts: 687
    
    1
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

Joined: Jan 30, 2000
Posts: 18671
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...


"I'm not back." - Bill Harding, Twister
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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

Joined: Aug 10, 2005
Posts: 687
    
    1
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

Joined: Aug 10, 2005
Posts: 687
    
    1
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.
 
 
subject: Number of JVMs in a CPU