From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,6e940fd5ba87c3ce X-Google-Attributes: gid103376,public X-Google-Thread: fdb77,ebcb336c62963fb4 X-Google-Attributes: gidfdb77,public X-Google-ArrivalTime: 2003-04-15 18:07:20 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: xanthian@well.com (Kent Paul Dolan) Newsgroups: comp.lang.java.advocacy,comp.lang.ada Subject: Re: real-time Java Date: 15 Apr 2003 18:07:20 -0700 Organization: http://groups.google.com/ Message-ID: References: <5ad0dd8a.0304150959.b35340e@posting.google.com> <0eidnSyVZLlWzwGjXTWcpQ@gbronline.com> NNTP-Posting-Host: 129.8.249.129 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1050455240 32451 127.0.0.1 (16 Apr 2003 01:07:20 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 16 Apr 2003 01:07:20 GMT Xref: archiver1.google.com comp.lang.java.advocacy:62236 comp.lang.ada:36175 Date: 2003-04-16T01:07:20+00:00 List-Id: Wesley Groleau 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.