On Sun, 3 Jan 1999, Richard Hall wrote:
> I believe that you can compile Java support into your kernel, or perhaps
> as a module. In other words, what you want does exist. Check into
> building a new kernel or using modules.
I've used it. It's no more than a cute trick for loading the jvm: it even
runs the java script.
The commands
java fred
&
fred.class
are equivalent if "fred.class" can be found in a directory mentioned in
${PATH}.
I've not looked at any java source code, and I'm not knowledgeable in Unix
programming, so I'll draw a parallel with OS/2 and hope it makes some
sense.
OS/2 users have a choice between two web browsers: Netscape and IBM's
WebExplorer. Before the use of Frames, Javascript and Java became
widespread many (maybe even most) users preferred WebExplorer. The reason
most cited is that it's faster.
The reason, people said, is that most of the code's in Dynamic Link
Libraries (shared libraries for WIN* and OS/2): two instances of webex
started separately share most of their code and so (the second and
subsequent copy) starts more quickly. Quite likely the first gives the
appearance of starting more quickly as it doesn't have to load all the code
do do something.
I notice that the executable of recent OS/2 sendmails (and it's a recent
port) os less then three k. This means that, if it's running as a daemon,
additional sendmails start almost instantly.
I assume that Linux shared libraries give the same benefits, but reduced
load times can only be achieved if
1 The executables are created to use them
2 The JVM code is mostly stored in shared libraries
3 There's an existing JVM running (so the libraries are loaded)
The first two items are in the hands of Sun and the porters.
Another item that can seriously degrade startup time and perhaps is
subsequent performance is the number of directories and files in
${CLASSPATH}. Carefully crafting it for each application can provide some
benefit.
On the whole, thouhg, I'd not expect scintillating performance from a 486.
One of the unresolved penalties of java is its overhead. Interpretation
costs about an order of magnitude more CPU than native code. For developed
code you could explore the field of java-to-native compilers: there are
several around.
--
Cheers
John Summerfield
http://os2.ami.com.au/os2/ for OS/2 support.
Configuration, networking, combined IBM ftpsites index.
