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: fdb77,ebcb336c62963fb4 X-Google-Attributes: gidfdb77,public X-Google-Thread: 103376,6e940fd5ba87c3ce X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-04-15 10:59:11 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: wojtek@power.com.pl (Wojtek Narczynski) Newsgroups: comp.lang.java.advocacy,comp.lang.ada Subject: Re: real-time Java Date: 15 Apr 2003 10:59:10 -0700 Organization: http://groups.google.com/ Message-ID: <5ad0dd8a.0304150959.b35340e@posting.google.com> References: NNTP-Posting-Host: 80.55.195.178 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1050429551 30626 127.0.0.1 (15 Apr 2003 17:59:11 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 15 Apr 2003 17:59:11 GMT Xref: archiver1.google.com comp.lang.java.advocacy:62175 comp.lang.ada:36169 Date: 2003-04-15T17:59:11+00:00 List-Id: Wesley Groleau wrote in message news:... > >>>How the heck you do that with a language subject to garbage collection > >>>is going to be an interesting thing to watch happen. > > Don't know much about it, but I read more than a year ago > that some company had a JVM with "guaranteed deterministic" > timing. Yes, garbage collector can be deterministic thus realtime. But in practice my experience with java libraries is that the developers relieved of the necessity to free memory explicitly, tend to forget about memory management completely (i.e. not clear stale references). You're stuck with OutOfMemoryError even though there is no "garbage" per se in the running app, and you really cannot do much. You cannot contact the vendor and say - "your library leaks". > How about a garbage collector in a lower priority > task that runs continuosly for some percentage of > CPU time instead of hogging the machine only when > desperately needed? This is how it works in current JVMs, stop-the-world collectors are past. > (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. Something that could be shared is the bytecodes loaded from .class files. This really is way redundant, for example eats extra 128MB of on my server. Unfortunately you cannot fork() a JVM as it is (usually) threaded. Having said all that, I'd stay away from real time java :-). I already imagine those ads "Parse your XML metadata schema transformation UML digital assets in realtime!". Hmm, I didn't know I'd constitute such a good marketing manager. (Sorry for an offtopic post.) Regards, Wojtek