Date: Fri, 7 Aug 1998 22:18:00 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: nate@mt.sri.com (Nate Williams) Cc: tlambert@primenet.com, jdp@polstra.com, chat@FreeBSD.ORG Subject: Re: Heads up on LFS Message-ID: <199808072218.PAA01251@usr02.primenet.com> In-Reply-To: <199808071637.KAA19141@mt.sri.com> from "Nate Williams" at Aug 7, 98 10:37:22 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > Q1: Is there more than 0 bytes difference between memory > > allocated and in use? > > Are you talking theoretically, or in actual use? Given that Modula-3 > and Java are close cousins, I can say with assurance that *most* > programs that are highly dynamic (C-use malloc alot, Java-use new alot) > use less memory than their appropriate C counterpart, because the GC is > *more* effecient than the C programmer at getting rid of unused memory. > > So in fact, there is *less* memory in use than in a C program. I don't think the GC is more efficient than the programmer, unless we are talking about a lazy programmer, or we are talking about scope restriction and large auto variables (where the compiler notes the variable is not being used and explicitly sends it out of scope after its last use instead of at the end of the function where the programmer explicitly states the function scope has ended). Even so, I would claim that the use of large auto variables is in fact a coding error, since it presumes, perhaps incorrectly, a large stack. Assuming a large stack is as bad as assuming a large heap, in my book. > > Q2: If so, how large can this number be under the worst > > possible conditions? > > If you are really careful in C, this number can be larger in Java (and > Modula-3 I suspect) by at most the amount of memory you can allocate in > 100ms. In C this # would the amount of memory you can allocate in one > realloc before the following free is called, so I suspect the results > are simliar. This is exactly my concern with GC'ing: how big a memory bubble it is possible to float. You *could* tie the act of allocation to the act of GC'ing (many LISP reclaimer implementations did this), which could give you a virtual working set quota (almost), but this is really a kludge. > > Q3: Is this more memory than is typically found in a > > typical embedded ssytem, such as the one found in a > > Microwave oven? > > This is irrelevant to the discussion, since the size/type of the objects > being allocated in both applications will be relevant to the embedded > system. It was merely an example of an embedded system with traditionally tight memory which you might want to put a JAVA-based UI on (this is especially true if the alternative were Windows CE... 8-)). If you prefer, I can re-ask it as "What is the smallest memory footprint in which I can reasonable expect to be able to run?". > > Q4: What is the typical target platform for an RT OS, and what > > is one of the major target platforms for JAVA? > > A small (1-2MB memory) box. That is what Personal Java is targetted > for. Note, the problem with Java (I can speak for Modula-3 here) in > many embedded systems is *NOT* the memory use (far from it), but the > timing issues. Java provides no real-hard time response to signals, and > really has no way for external inputs to happen in any speed. If you were to do as I suggested, above, and tie allocation to the GC to reduce maximum pool size, the performance would be even worse, unfortunately, since you would eat intermittent GC latencies. 8-(. I think using a non-JVM based JAVA (ie: a JAVA chip) would go a long way toward alleviating this. > For a really good discussion of this check out the advanced-java > archives on xcf.berkeley.edu from a year or more ago. It has been > discussed to death there. Thanks. I have archived this location for later reference. > > Q5: How provable is a system that depends on garbage collection? > > They are in use today, being sold as consumer items to real people for > real problems. > > Again, you are obviously speaking out of ignorance, and should go read > up on both Java and Modula-3, Garbage collection techniques, and object > oriented programming in your spare time. "Provable", not "probable". That was not a typo. I am speaking of correctness proofs. I'll answer it for you: adding async resource recovery to any system makes it much harder to prove (ie: determinism, ensuring failsafe, and fault tolerance, standard requirements placed on embedded systems). Even with that last snipe, this is a much more productive discussion than the other. Thank you. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199808072218.PAA01251>