A little more to the point which I was less clear on is if the
same cost extends to a subsequent runtime launched java process? Or
is there some savings in having a java vm already going starting a
new java child process? Something like...
....
Process proc = Runtime.getRuntime().exec(args);
....
For launching 100 jvms there is some time taken. For launching one
bootstrap child process it would undoubtedly be less. The odds of
my ending up with a bootstrap process + 99 java plugins is somewhat
small. Would the ones I have launch as quickly as what this test
shows? No. So you are also correct this test isn't really
representative. Real or at least interesting fake java processes
would have real or at least interesting fake things for more
realistic measurements.
You're asking good questions. FWIW, I had Eclipse open in the
background during the Java launch test so whatever portion of the JVM
is shared should have been continuously available. Runtime.exec
spawns a new OS-level process using the same system calls that are
used when launching a process from bash (e.g. fork and execv or
something similar). However, your intuition is on the right track.
You can use an existing JVM to launch another one and avoid some of
the startup time, though I forget exactly how to do it. If you're
interested, I'll dig up some examples.
The main ramification of the kind of benchmark provided is that the
Unix-style stringing of simple, utility programs can be much less
efficient in Java. Of course, if you put all of the needed
functionality into a single Java application, the performance will be
far better. This is the technique of the (c language) busybox
project: http://www.busybox.net/
Cheers,
Dominic
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
