Chris Oliver's Weblog

Wednesday Nov 29, 2006

Poor man's Multi-VM

The most recent demos on my weblog are run as separate applications in the same JVM. In addition to its own F3 interpreter, each individual demo gets its own class loader, thread-group, and AWT event-dispatch thread. This is accomplished by using features also used in the applet plugin. Note that this approach isn't specific to F3, but could be used with any Swing application. You can manually kill the applications (which is implemented in the same way that applets are destroyed when you leave a web page). In addition, it installs a security manager that traps System.exit() and destroys the application context of the application rather than exiting the JVM. Some of the F3 demos may appear to start slowly, but that's due to the overhead of F3 or to the fact that many images are being loaded from the network or file system, and not due to the JVM. Self-contained Swing apps (such as SwingSet2) would start instantaneously.

I was prompted to do this by Gilad Bracha (who unfortunately left Sun recently). Gilad told me that he didn't believe in Java GUI's for two reasons:

  1. Start-up time
  2. Footprint

He mentioned a test they did comparing the SmallTalk Squeak IDE, which started up in about 3 seconds and used about 25M of memory, compared to Netbeans which in this test took a minute to start up and used over 100M. But of course you may not consider this a fair test. So next they simply took a screenshot of the Squeak IDE and then wrote a tiny Java program just to display the screenshot. This second program took 3 seconds to start up and also used about 25M of memory, but in the first case we had a fully-functioning SmallTalk IDE and in the other just a bitmap.

I personally found his arguments undeniable.

I did my own tests where I ran 10 instances of SwingSet2 in separate JVMs versus in the same JVM but with separate application contexts. In the former case total memory use was 540M, in the latter 74M.

As I mentioned this approach isn't specific to F3.

I put a zip file containing the basic code to do this for regular Swing applications here (45kb).

Note: this is just example code to illustrate how you could do this.

The zip file contains the source and compiled code and some windows batch files to build and run it (Java 1.6 required to build, Java 1.5 to run).

There's only one class called JApplication. You call its main method with a class path and class name similar to how you run the java command, e.g.

java com.sun.JApplication -classpath SwingSet2.jar SwingSet2

When you run it the first time it creates a server socket on the local host and listens for subsequent connections. At the same time it creates a new thread group, class loader, and application context and runs the application you specified (i.e in this case SwingSet2). When you run it subsequent times it simply connects to the port and writes the command line argument over the socket. The original then creates a new thread group, class loader, and application context as above and runs it in the address space of the original vm. In addition, writes to System.out and System.err from that thread group are redirected back to the socket so you see the console output of your application as expected. It would also be possible to write a C program or shell script to launch your application (rather than using another JVM).

Finally, if you're using Java 1.6 it adds an icon to the system tray which has a menu to shut down the whole thing and also can display a window listing the running applications and which allows you to kill them manually.

Note that this example code doesn't handle security issues at all.

Comments:

The end to the issue will only come when (something like) this is made seamless for all java desktop apps on a single desktop user session. The current situation is untenable, especially for java plugins. Compare the performance and overhead of NS 4.7 (where Java did this) to a browser with any Sun plugin.

Posted by Neil Corlett on November 29, 2006 at 10:48 AM PST #

release it!

Posted by releaseit on November 29, 2006 at 05:06 PM PST #

Hi Chris--there are at least two projects over the years which did the same thing, Echidna and Nailgun. Echidna was eventually abandoned, but was picked up and shipped with Jsh, where it is still used. Nailgun got to about 0.7. NG had a neat idea, in that a small C program (executable) was used to send new requests to the server. Since that program was tiny, you were essentially streaming a tiny command string to the server, who'd execute it and stream results back--he handled stdio and stderr, from what I recall. Jsh has some demos/screenshots of loading many Java apps at the same time. I've been thinking that it would make the most sense to use a web container, e.g. just a host for "Servlet" (not HttpServlet) instances, each of which is the entry point for an app, since there are many secondary concerns which web container hosts already deal with. I do like how the F3 apps start, though. Patrick

Posted by Patrick Wright on November 30, 2006 at 06:05 AM PST #

These demos are awesome, as is your "MVM." I was battling to do a similar thing with "CookieJar" which thanks to your example code, now i got some clues and examples for SecurityManager, ApplicationContext, and SystemTray - thanks for that :) I would like to write a "walk through" article on your JApplication class - would that be OK?

Posted by evanx on December 01, 2006 at 12:55 AM PST #

evanx: Sure, go ahead.

Posted by Chris Oliver on December 01, 2006 at 10:33 AM PST #

Chris

Sorry, but your writeup is incomplete without an explanation of the observed behaviour. For that if it matters, I've seen complete 32 bit Windows GUI programs that were less than 25KB in size. (They were coded in assembly).

The issues are closely related to what each of the approaches are trying to accomplish and with what philosophy.

Java, with Swing, tries to bring a cross-platform GUI toolkit. However, it fails to live up to the "instant on" crowd's expectations because of what I believe were philosophical decisions taken in development of Swing and Java implementation.

The JVMs do not even try to optimize the load times. The JIT kicks in late after profiling, JAR caching etc are ideal for applications whose run time is much longer than startup time, but little else.

Secondly, the Swing approach of virtualizing everything on the canvas and only using the least common denominator OS services had its own advantages and disadvantages. Advantages were more in line with consistency (though in practice it became equally-inconsistent) and customizable & richer widget set. I also believe they would have thought about the programming model too, now that it wasn't tied to particular ways different OSs try to do GUI (eg. multi/single thread event dispatching etc etc) and I believe they'd have thought about a lot of other possibilities, which would have been axed for being too "futuristic" and "out-of-ordinary".

So I do believe Swing designers were upto something, and not just plain wrong. The objectives ended up being different from expectations of "lean-mean" and "instant-on" crowds... but well, it's all not that bad too :-)

PS: I'm shocked to see Gilad leaving too. What is Jonathan doing ????

- Akhilesh

Posted by Akhilesh Mritunjai on December 02, 2006 at 06:05 AM PST #

Hi, Great piece of code. Enjoyed reading it. However, when I run the java command a subsequent time, I creates a 9MB java process again. But if 9MB is lost with invocation of every next java swingset app, one still looses RAM. I have tried xito, and with all due respect, I liked it because it does not spawn multiple java processes for every new app. http://xito.sourceforge.net/ Could someone compare this with xito app manager. Thanks, Vinay

Posted by Vinay Soni on December 03, 2006 at 10:54 PM PST #

Thanks Chris, check out the following draft, lemme know if it's ok, http://aptframework.dev.java.net/article/f3mvm.html

Posted by evanx on December 04, 2006 at 02:10 PM PST #

Has anyone figured out how to parse strings to numbers in F3? Integer.parseInt doesn't work because Integer means something different in F3. I'm enjoying playing around with F3Pad...

Posted by Andy White on December 05, 2006 at 05:29 AM PST #

Hi, I am very impressed with F3. Could you give some performance comparison of F3 to Java. Are you planning a JIT compiler for F3?

Posted by Deniz Oguz on December 06, 2006 at 11:03 PM PST #

[Trackback] In "Poor Man's Multi-VM" Chris Oliver discusses his JApplication class, which he uses for his awesome F3 demos. Let's walk through the code, and see how deep the rabbit hole goes ;)

Posted by Evan Summers's Blog on December 10, 2006 at 12:54 PM PST #

I'm curious if in your "10 JVMs" test whether you simply added up the process memory each process reported, or did you consider, and subtract, the amount of shared memory the JDK 5 Class Sharing system shared across all 10 JVMs.

It's my understanding that the class sharing is designed to address this specific concern in terms of excess resource usage.

But that's not readily apparent from simply adding up the combined process sizes, as they each report what is in fact shared memory.

Posted by Will on December 11, 2006 at 04:24 PM PST #

Um, what is F3? That "Links" section, you know… maybe you could put a link to some explanation.

Posted by 71.195.202.79 on December 11, 2006 at 09:35 PM PST #

A useful thing; thanks for posting it. I didn't see any per-app setting of the default directory for relative paths. Is there some way to do this?

Posted by Chris Thiessen on December 13, 2006 at 07:05 AM PST #

From one of the quotes above:

...with Swing, tries to bring a cross-platform GUI toolkit. However, it fails to live up to the "instant on" crowd's expectations because of what I believe were philosophical decisions taken in development of Swing and Java implementation.

I don't think the philosophical decisions were that different from those of the commercial Smalltalk VisualWorks. They both provide their own GUI toolkits that are platform independent and use them to simulate the platform they start up on. VisualWorks Smalltalk has done cross-platform GUI's since 1994 or so. The applications are faster at starting up and have a smaller memory footprint than an equivalent Java application. What you trade though is all the security and sandboxing, but for a desktop application, you aren't typically loading class files over the internet, etc.

The VW VM is very competitive in performance even with the latest Java releases including HotSpot and uses many of the same techniques, which if you have read about Strongtalk, that were originally aimed at Smalltalk and were then retargeted to Java after SUN bought the company.

IMO, VisualWorks is still a leader when you talk about powerful, crossplatform GUI frameworks. It was and is a truely write-once run everywhere. (Excluding custom C extensions for which Java has the same issue). VisualWorks is a very competitive Cross Platform development environment supporting DB's, Web Services, Distributed Programming, CORBA, etc.

You can learn more here: Cincom Smalltalk

Having said all that, this work on F3 is exciting and very relavant to the needs of real developers.

Posted by Sam Griffith Jr on December 14, 2006 at 03:30 AM PST #

Echoing Will's comment above - when measuring multiprocess memory usage on Windows, summing up Task Manager entries doesn't account for shared memory. The solution is to use a tool such as vadump.exe to get the correct accounting. I wrote it up with some more detail here: Share and Enjoy: Memory Usage of Multiple Java Processes on Windows.

That said, many thanks for F3 and also for pushing the limits of classloader-based containers with JApplication!

Posted by sbohne on January 12, 2007 at 07:52 AM PST #

Hi, Chris.

Two quickies:

1) What license is JApplication released under?

2) Spotted a small bug: the classloader cache lookup always fails as it's using String[] keys. Changing these to use the "urls" linked lists fixes this.

Posted by chocolateboy on February 18, 2007 at 12:28 AM PST #

Thanks Best Regards

Posted by mirc on April 05, 2008 at 09:14 AM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed

Calendar

Feeds

Search

Links

Navigation

Referers