Re: real-time Java

[xanthian@well.com (Kent Paul Dolan)]

Wesley Groleau <wesgroleau@despammed.com> wrote (and
butchered the attributions on):

>>> (Another thing that would be nice is a JVM that is a
>>> shared library or resident in the OS or something,
>>> instead of--this is for multi-user environments, BTW--
>>> having every Java program running its own copy of the
>>> JVM.)

>> Unix and Windows will load only one copy of a binary no
>> matter if it's an executable or shared library. So there
>> is only one copy of the garbage collector code. I don't
>> see how collector data could be shared though.

> I can't speak for windows, but this is not true of
> Solaris.

Since when? Normal Unix behavior is that a virtual memory
page from a disk image of an executable is only physically
replicated if one or another of the referring routines makes
it "dirty"; otherwise, while it is being used "read-only",
all referring routines thread through a single virtual
memory copy. If it is made dirty, the reference count to the
clean copy is reduced, and the routine attempting to write
to it gets a private copy on which to scribble.

So long as the compiler and linker provide a clean division
between executing code and its mutable data, most of the
code image should be shared.

Since I used to run _many_ executables with 100 megabyte
codespace footprints in Solaris on UltraSparcs
simultaneously without running out of memory, your claim
seems suspect, but I'm not privy to Solaris internals to
refute it.

> The project I recently left had a problem reporting /
> tracking tool in Java.  Everybody used it.  That mean that
> at any given time, the physical memory and swap space had
> twenty to thirty copies of the JVM running, and each copy
> had additional memory allocated to all the same classes.

Hmm, that does raise an interesting point, though.  Even if
the JVM code space were shared, the classes are JVM _data_,
not underlying OS _code_, and so might not be sharable,
unless the clean page/dirty page rules above hold for _any_
disk page images (which might well be the case).  Even then,
there is next to no way the JIT native code could be shared,
but perhaps it is a relatively small item compared to the
classes from which it is compiled, since it is only the hot
loops of those classes.

xanthian.