* Re: real-time Java [not found] <bebbba07.0304101816.3493f42a@posting.google.com> @ 2003-04-11 6:10 ` Kent Paul Dolan 2003-04-11 6:23 ` Dr. Michael Paus ` (2 more replies) 0 siblings, 3 replies; 17+ messages in thread From: Kent Paul Dolan @ 2003-04-11 6:10 UTC (permalink / raw) 18k11tm001@sneakemail.com (Russ) wrote: > I've been hearing a lot lately about real-time Java. I must confess > I'm baffled about the motivation behind this endeavor. Would someone > please tell me what real-time Java will be able to do that Ada can't > do? Or what it will be able to do better than Ada? Thanks. Sure: bring a popular, thriving, employer-demanded language with a wealth of libraries and a robust built-in GUI into the real time arena. xanthian. How the heck you do that with a language subject to garbage collection is going to be an interesting thing to watch happen. Some complaints in comp.lang.java.programmer mention Java going off to stew for whole minutes at a time. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: real-time Java 2003-04-11 6:10 ` real-time Java Kent Paul Dolan @ 2003-04-11 6:23 ` Dr. Michael Paus 2003-04-17 6:40 ` Kent Paul Dolan 2003-04-11 11:43 ` Tum 2003-04-15 8:17 ` Darren Winsper 2 siblings, 1 reply; 17+ messages in thread From: Dr. Michael Paus @ 2003-04-11 6:23 UTC (permalink / raw) Kent Paul Dolan wrote: > 18k11tm001@sneakemail.com (Russ) wrote: > > >>I've been hearing a lot lately about real-time Java. I must confess >>I'm baffled about the motivation behind this endeavor. Would someone >>please tell me what real-time Java will be able to do that Ada can't >>do? Or what it will be able to do better than Ada? Thanks. > > > Sure: bring a popular, thriving, employer-demanded language with a > wealth of libraries and a robust built-in GUI into the real time > arena. > > xanthian. > > How the heck you do that with a language subject to garbage collection > is going to be an interesting thing to watch happen. Some complaints > in comp.lang.java.programmer mention Java going off to stew for whole > minutes at a time. If you are interested in how this can be achieved, have a look at http://www.aicas.com/ They sell a real-time capable VM. Of course you cannot expect real-time behaviour from a standard VM from Sun on a non-real-time OS like Windows. Nevertheless the statement that Java stops for minutes to do some garbage collection is simply wrong for modern VMs. Michael ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: real-time Java 2003-04-11 6:23 ` Dr. Michael Paus @ 2003-04-17 6:40 ` Kent Paul Dolan 2003-04-17 21:04 ` Robert A Duff 0 siblings, 1 reply; 17+ messages in thread From: Kent Paul Dolan @ 2003-04-17 6:40 UTC (permalink / raw) "Dr. Michael Paus" <paus@ib-paus.com> wrote: > Kent Paul Dolan wrote: >> How the heck you do [hard real time >> execution] with a language subject to >> garbage collection is going to be an >> interesting thing to watch happen. >> Some complaints in >> comp.lang.java.programmer mention >> Java going off to stew for whole >> minutes at a time. > If you are interested in how this can > be achieved, have a look at > http://www.aicas.com/ Thanks for that. Their software would probably achieve faster acceptance if the book convincing people it was possible at all were freely available online, but I cannot make their business decisions for them, and my viewpoint may be biased by poverty. > Nevertheless the statement that Java > stops for minutes to do some garbage > collection is simply wrong for modern > VMs. I'm not quite sure how you can categorize as "wrong" the experiences reported by many programmers. What they are reporting certainly _happens_. Whether what they are reporting is due to the conceptual difficulty of programming for a garbage collecting language implementation, [GC, it should be emphasized, was created mostly to overcome the conceptual difficulty of programming with explict new/dispose commands, and if conceptual difficulty is still the main problem, then garbage collection is not yet a programming tool which satisfies its design goal.] or whether what they are reporting is due to inherent limitations of garbage collection technology today as a mechanism, or whether what they are reporting is the result of flawed GC implementations today, the problem still certainly exists. Solving it in all three forms needs to be a priority issue for Java Virtual Machine implementors, Java language design mavins, and Java tutorial writers, since GC problems are one of the most frequent causes of criticisms of Java and slowness of Java programming language acceptance. xanthian. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: real-time Java 2003-04-17 6:40 ` Kent Paul Dolan @ 2003-04-17 21:04 ` Robert A Duff 0 siblings, 0 replies; 17+ messages in thread From: Robert A Duff @ 2003-04-17 21:04 UTC (permalink / raw) xanthian@well.com (Kent Paul Dolan) writes: > Whether what they are reporting is due > to the conceptual difficulty of > programming for a garbage collecting > language implementation, > > [GC, it should be emphasized, was > created mostly to overcome the > conceptual difficulty of programming > with explict new/dispose commands, and > if conceptual difficulty is still the > main problem, then garbage collection > is not yet a programming tool which > satisfies its design goal.] > > or whether what they are reporting is > due to inherent limitations of garbage > collection technology today as a > mechanism, or whether what they are > reporting is the result of flawed GC > implementations today, the problem still > certainly exists. Part of the problem is that Java wants to put (almost) everything in the heap. The GC would be faster if more data could be allocated in the stack, or in registers. Many GC'ed languages share this problem. The C# language is nearly identical to Java, but one important difference is that you can have stack-allocated structs. - Bob ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: real-time Java 2003-04-11 6:10 ` real-time Java Kent Paul Dolan 2003-04-11 6:23 ` Dr. Michael Paus @ 2003-04-11 11:43 ` Tum 2003-04-15 8:17 ` Darren Winsper 2 siblings, 0 replies; 17+ messages in thread From: Tum @ 2003-04-11 11:43 UTC (permalink / raw) Check out wonka. http://wonka.acunia.com/ It's free. "Kent Paul Dolan" <xanthian@well.com> wrote in message news:a3eaa964.0304102210.3875f527@posting.google.com... > 18k11tm001@sneakemail.com (Russ) wrote: > > > I've been hearing a lot lately about real-time Java. I must confess > > I'm baffled about the motivation behind this endeavor. Would someone > > please tell me what real-time Java will be able to do that Ada can't > > do? Or what it will be able to do better than Ada? Thanks. > > Sure: bring a popular, thriving, employer-demanded language with a > wealth of libraries and a robust built-in GUI into the real time > arena. > > xanthian. > > How the heck you do that with a language subject to garbage collection > is going to be an interesting thing to watch happen. Some complaints > in comp.lang.java.programmer mention Java going off to stew for whole > minutes at a time. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: real-time Java 2003-04-11 6:10 ` real-time Java Kent Paul Dolan 2003-04-11 6:23 ` Dr. Michael Paus 2003-04-11 11:43 ` Tum @ 2003-04-15 8:17 ` Darren Winsper 2003-04-15 9:23 ` Mark Thornton 2 siblings, 1 reply; 17+ messages in thread From: Darren Winsper @ 2003-04-15 8:17 UTC (permalink / raw) In <a3eaa964.0304102210.3875f527@posting.google.com>, Kent Paul Dolan wrote: > How the heck you do that with a language subject to garbage collection > is going to be an interesting thing to watch happen. By using things like immortal and scoped memory. Check out the Memory classes in the RTJ spec. -- A wise man learns from his mistakes. |ICQ:8899775 A sage learns from the mistakes of others. |JID:darren@rooter.dyndns.org My own incompetence shall lead to a better world. |MSN:punjabpete@hotmail.com ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: real-time Java 2003-04-15 8:17 ` Darren Winsper @ 2003-04-15 9:23 ` Mark Thornton 2003-04-15 14:57 ` Wesley Groleau 0 siblings, 1 reply; 17+ messages in thread From: Mark Thornton @ 2003-04-15 9:23 UTC (permalink / raw) "Darren Winsper" <dw133@cs.york.ac.uk.go.away> wrote in message news:pan.2003.04.15.08.17.02.790560@cs.york.ac.uk.go.away... > In <a3eaa964.0304102210.3875f527@posting.google.com>, Kent Paul Dolan > wrote: > > > How the heck you do that with a language subject to garbage collection > > is going to be an interesting thing to watch happen. > > By using things like immortal and scoped memory. Check out the Memory > classes in the RTJ spec. > And also by choosing an appropriate garbage collector. Some real time tasks can tolerate the delays introduced by a garbage collector. Mark Thornton ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: real-time Java 2003-04-15 9:23 ` Mark Thornton @ 2003-04-15 14:57 ` Wesley Groleau 2003-04-15 15:06 ` Mark Thornton ` (2 more replies) 0 siblings, 3 replies; 17+ messages in thread From: Wesley Groleau @ 2003-04-15 14:57 UTC (permalink / raw) >>>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. > And also by choosing an appropriate garbage collector. Some real time tasks > can tolerate the delays introduced by a garbage collector. 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? (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.) ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: real-time Java 2003-04-15 14:57 ` Wesley Groleau @ 2003-04-15 15:06 ` Mark Thornton 2003-04-15 15:50 ` Robert A Duff 2003-04-15 17:59 ` Wojtek Narczynski 2 siblings, 0 replies; 17+ messages in thread From: Mark Thornton @ 2003-04-15 15:06 UTC (permalink / raw) "Wesley Groleau" <wesgroleau@despammed.com> wrote in message news:Jj6dnZQ3ZIVegAGjXTWcpg@gbronline.com... > >>>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. > > > And also by choosing an appropriate garbage collector. Some real time tasks > > can tolerate the delays introduced by a garbage collector. > > 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? > > (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.) > In addition to the standard garbage collector the current Sun JVM has 3 other collectors: 1) an incremental collector 2) a concurrent collector 3) a parallel collector http://java.sun.com/j2se/1.4.1/changes.html#vm Mark Thornton ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: real-time Java 2003-04-15 14:57 ` Wesley Groleau 2003-04-15 15:06 ` Mark Thornton @ 2003-04-15 15:50 ` Robert A Duff 2003-04-16 23:29 ` Thomas Maslen 2003-04-15 17:59 ` Wojtek Narczynski 2 siblings, 1 reply; 17+ messages in thread From: Robert A Duff @ 2003-04-15 15:50 UTC (permalink / raw) Wesley Groleau <wesgroleau@despammed.com> writes: > Don't know much about it, but I read more than a year ago > that some company had a JVM with "guaranteed deterministic" > timing. I wonder if the machine it runs on (I mean the real one, not the virtual one) has a cache. Also, I don't think "deterministic" is quite what you want. You want some practical way of predicting a worst-case (bounded) time during which GC locks out other tasks. > 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? That sort of thing can be done, but any GC is going to need *some* amount of time to do stuff that can't be interrupted. Designs that reduce such times often increase the overall overhead, so there's a tradeoff. - Bob ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: real-time Java 2003-04-15 15:50 ` Robert A Duff @ 2003-04-16 23:29 ` Thomas Maslen 0 siblings, 0 replies; 17+ messages in thread From: Thomas Maslen @ 2003-04-16 23:29 UTC (permalink / raw) In <wccllybiwu2.fsf@shell01.TheWorld.com> Robert A Duff <bobduff@shell01.TheWorld.com> writes: >Wesley Groleau <wesgroleau@despammed.com> writes: > >> Don't know much about it, but I read more than a year ago >> that some company had a JVM with "guaranteed deterministic" >> timing. > >I wonder if the machine it runs on (I mean the real one, not the virtual >one) has a cache. Dunno about that JVM, but aJile's aJ-80 and aJ-100 Java CPU chips were designed with realtime Java in mind and don't have caches in the normal sense. (They do have on-chip RAM, and I think that current versions of the firmware for J2ME use some of it as a stack cache, but that's not quite the same). Thomas Maslen maslen@pobox.com ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: real-time Java 2003-04-15 14:57 ` Wesley Groleau 2003-04-15 15:06 ` Mark Thornton 2003-04-15 15:50 ` Robert A Duff @ 2003-04-15 17:59 ` Wojtek Narczynski 2003-04-15 18:43 ` Wesley Groleau 2003-04-15 18:47 ` Wesley Groleau 2 siblings, 2 replies; 17+ messages in thread From: Wojtek Narczynski @ 2003-04-15 17:59 UTC (permalink / raw) Wesley Groleau <wesgroleau@despammed.com> wrote in message news:<Jj6dnZQ3ZIVegAGjXTWcpg@gbronline.com>... > >>>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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: real-time Java 2003-04-15 17:59 ` Wojtek Narczynski @ 2003-04-15 18:43 ` Wesley Groleau 2003-04-15 23:33 ` Samuel Tardieu 2003-04-16 1:07 ` Kent Paul Dolan 2003-04-15 18:47 ` Wesley Groleau 1 sibling, 2 replies; 17+ messages in thread From: Wesley Groleau @ 2003-04-15 18:43 UTC (permalink / raw) >>(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. 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: real-time Java 2003-04-15 18:43 ` Wesley Groleau @ 2003-04-15 23:33 ` Samuel Tardieu 2003-04-16 1:07 ` Kent Paul Dolan 1 sibling, 0 replies; 17+ messages in thread From: Samuel Tardieu @ 2003-04-15 23:33 UTC (permalink / raw) >>>>> "Wes" == Wesley Groleau <wesgroleau@despammed.com> writes: >> 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. Wes> I can't speak for windows, but this is not true of Solaris. The Wes> project I recently left had a problem reporting/tracking tool in Wes> Java. Everybody used it. That mean that at any given time, the Wes> physical memory and swap space had twenty to thirty copies of the Wes> JVM running, and each copy had additional memory allocated to all Wes> the same classes. "All the same classes" are data. Wojtek was talking about the virtual machine itself (including the garbage collector), not about all the loaded classes. Fortunately, only read-only pages are shared, not data :-) Sam -- Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/sam ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: real-time Java 2003-04-15 18:43 ` Wesley Groleau 2003-04-15 23:33 ` Samuel Tardieu @ 2003-04-16 1:07 ` Kent Paul Dolan 1 sibling, 0 replies; 17+ messages in thread From: Kent Paul Dolan @ 2003-04-16 1:07 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: real-time Java 2003-04-15 17:59 ` Wojtek Narczynski 2003-04-15 18:43 ` Wesley Groleau @ 2003-04-15 18:47 ` Wesley Groleau 2003-04-16 5:16 ` Tor Iver Wilhelmsen 1 sibling, 1 reply; 17+ messages in thread From: Wesley Groleau @ 2003-04-15 18:47 UTC (permalink / raw) > 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". I was amused at JBuilder one day. I pulled down an "info" menu option. At the bottom of the little widget that popped up was the amount of memory in use. Even though I was doing absolutely nothing, the number kept slowly rising. When it hit some threshold, GC was triggered and it started over. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: real-time Java 2003-04-15 18:47 ` Wesley Groleau @ 2003-04-16 5:16 ` Tor Iver Wilhelmsen 0 siblings, 0 replies; 17+ messages in thread From: Tor Iver Wilhelmsen @ 2003-04-16 5:16 UTC (permalink / raw) Wesley Groleau <wesgroleau@despammed.com> writes: > I was amused at JBuilder one day. I pulled down an > "info" menu option. At the bottom of the little widget > that popped up was the amount of memory in use. Even though > I was doing absolutely nothing, the number kept slowly rising. Welcome to the wonderful world of non-immutable events leading to tons of events created and discarded in any given Swing application as it runs. Even if you did absolutely nothing, Swing (and possibly JBuilder's "virtual file system") was generating events like asking itself if it needed to repaint etc. ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2003-04-17 21:04 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <bebbba07.0304101816.3493f42a@posting.google.com> 2003-04-11 6:10 ` real-time Java Kent Paul Dolan 2003-04-11 6:23 ` Dr. Michael Paus 2003-04-17 6:40 ` Kent Paul Dolan 2003-04-17 21:04 ` Robert A Duff 2003-04-11 11:43 ` Tum 2003-04-15 8:17 ` Darren Winsper 2003-04-15 9:23 ` Mark Thornton 2003-04-15 14:57 ` Wesley Groleau 2003-04-15 15:06 ` Mark Thornton 2003-04-15 15:50 ` Robert A Duff 2003-04-16 23:29 ` Thomas Maslen 2003-04-15 17:59 ` Wojtek Narczynski 2003-04-15 18:43 ` Wesley Groleau 2003-04-15 23:33 ` Samuel Tardieu 2003-04-16 1:07 ` Kent Paul Dolan 2003-04-15 18:47 ` Wesley Groleau 2003-04-16 5:16 ` Tor Iver Wilhelmsen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox