Issues when running multiple apps on same JRE?

I've created an application that launches other Java applications, all running on the same JRE. I've noticed that this results in significant memory savings (60% or more). Performance doesn't seem to be measurably affected, but I've never run more than 4 applications at the same time on the same JRE.

Does anyone know of any performance issues in situations like this? JRE limitations? Any information would be appreciated.

[455 byte] By [msenecal] at [2007-9-26 1:43:00]
# 1

Multiple processes may get more CPU cycles compared to multiple threads under a single process (depending on OS implementation i sps). Still, the memory savings would probably outway this...

Also, if one app crashes the JVM (perhaps due to some sloppy JNI), it would bring down all your apps! Of course this is very rare...

rrmaclac at 2007-6-29 2:36:35 > top of Java-index,Desktop,Runtime Environment...
# 2

Oh, don't forget to load each application with a different classloader. Otherwise, the classes for each application will remain resident in the JVM even after the application has ended. This would produce a subtle memory leak...

There's probably a lot to learn from the design of Servlet engines as they can be viewed as several applications running under the same JVM...

rrmaclac at 2007-6-29 2:36:35 > top of Java-index,Desktop,Runtime Environment...
# 3

Does anyone, perchance, have a link for a technote or something that describes this responsibility of classLoaders?

I believe Ryan, of course. It's just not obvious from the 1.3 API docs that the classLoader is what's responsible for associating a set of classes with a set of threads.

I see potential for this pseudo-leak to cause problems if it isn't well-documented for developers of Web Start apps that happen to run other cached apps in order to use their services.

Joe Walp

walpj at 2007-6-29 2:36:35 > top of Java-index,Desktop,Runtime Environment...
# 4
This is all I've been able to find on the topic. Is there other documentation? http://developer.java.sun.com/developer/TechTips/2000/tt1027.html#tip3
walpj at 2007-6-29 2:36:35 > top of Java-index,Desktop,Runtime Environment...
# 5
There's a little more on classLoaders in the extension mechanism section of the tutorial, but it doesn't really give any more info than the API docs. http://java.sun.com/docs/books/tutorial/ext/basics/load.html
walpj at 2007-6-29 2:36:35 > top of Java-index,Desktop,Runtime Environment...
# 6
Here's a JavaWorld article on classLoaders. http://www.javaworld.com/javaworld/jw-03-2000/jw-03-classload.html
walpj at 2007-6-29 2:36:35 > top of Java-index,Desktop,Runtime Environment...
# 7

"It's just not obvious from the 1.3 API docs that the classLoader is what's responsible for associating a set of classes with a set of threads."

No, that's not what I was implying. The default classloader caches the definition of previously loaded classes (ie, bytecode, static variables). By default, there is no way to unload a class. Static variables will also retain their values -- which could confuse an application that is run multiple times.

This is the suggested implementation defined in the JVM spec:

http://java.sun.com/docs/books/vmspec/html/ConstantPool.doc.html

Basically, if a class has already been loaded, it returns it. You can write your own custom classload to prevent this (as the link you found suggests) or use multiple classloaders.

Imagine what happens when you write an application and then recompile a class WHILE running your application. Will the next instance of that class be updated? The answer depends on whether your classloader will reload the class from disk, or use a cached instance in memory (as the default one does).

rrmaclac at 2007-6-29 2:36:35 > top of Java-index,Desktop,Runtime Environment...
# 8

Yes, after reading those references I understood that compartmentalizing a set of classes in order to associate them with the threads of a second application is only one possible use of classLoaders.

See also this request in the JDC forum.

http://forum.java.sun.com/thread.jsp?forum=10&thread=154866

walpj at 2007-6-29 2:36:35 > top of Java-index,Desktop,Runtime Environment...
# 9
See also this older topic in the JVM forum. http://forums.java.sun.com/thread.jsp?forum=37&thread=70724Does anyone know what happened to Ted Neward's javageeks site?
walpj at 2007-6-29 2:36:35 > top of Java-index,Desktop,Runtime Environment...
# 10

Why not make this modemultiple apps in a single JREthe standard behavior for client-side Java?

In server-side Java, all app components are managed by an appserver that runs in one virtual machine per physical machine. Client-side Java could benefit from a standard application manager that loads all apps that are compatible with a particular JRE version in a single VM.

Please use this topic in the JCP forum to elaborate on motivations, issues and requirements for this migration.

http://forum.java.sun.com/thread.jsp?forum=25&thread=156163

walpj at 2007-6-29 2:36:35 > top of Java-index,Desktop,Runtime Environment...
# 11

I'm the maintainer of jsh (http://www.appliweb.net/jsh) which runs multiple applications in the same jvm.

There are many problems than simply using different classloaders, here are some :

- Applications always call System.exit (), so if nothing is done, when you quit one app, all others are gone too.

- Most applications expect to be run from their root directory. This means each one must have their own 'current directory' (user.dir property)

- Most must have their own classpath,

- They use static System classes, like when they set their own securitymanager, System.out, System.err, etc....

There are many more issues....

Grard

inf-collin at 2007-6-29 2:36:35 > top of Java-index,Desktop,Runtime Environment...