Date: Fri, 7 Aug 1998 16:50:34 -0600 From: Nate Williams <nate@mt.sri.com> To: Terry Lambert <tlambert@primenet.com> Cc: nate@mt.sri.com (Nate Williams), jdp@polstra.com, chat@FreeBSD.ORG Subject: Re: Heads up on LFS Message-ID: <199808072250.QAA22022@mt.sri.com> In-Reply-To: <199808072218.PAA01251@usr02.primenet.com> References: <199808071637.KAA19141@mt.sri.com> <199808072218.PAA01251@usr02.primenet.com>
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). *Right* And you've never written a program that leaked memory, nor had *any* errors due to malloc/free problems, or dealt with them. If you can say that every program you ever written that used dynamic memory has never had problems, then I don't believe you. Because there are problems, a GC scheme can (and oftentimes) does a better job because it keeps track of things for you. Studies have shown this to be true. > 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. Huh? Who said anything about large auto variable, and or a large heap. Again, you're jumping to conclusions w/out any basis on anything. > > > 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. Depends on too many things. In C the same problems exist with 'free' as well. Does the free implementation return it immediately to the OS, or just back onto the free list? Again, you can't say GC is worse than malloc/free in C, since both are *very* implementation and even OS dependant. > > > 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-)). I suspect a Java-based UI would be much smaller than a comparable Windows-CE based UI on it, but given that the pilot already has a working OS that is smaller than both this is really a moot point. > 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?". Depends on what you want to do? Do you want *everything* that I have on my FreeBSD/X box? > > > 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. You can't 'prove' anything significant. You *can* prove that the GC system will work, as many have done. Check out any of the Boem (sp?) stuff on Xerox-Parc's WWW site. > 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). Right, as as another poster already pointed out, once you start doing dynamic memory allocation (in either C, C++, or Java), all provability bets are off. As I stated before, GC isn't the problem here, the problem is timing and availability of resources. The previous poster already mentioned it, but I'll repeat what he said (much better than I). A language developered around GC system actually does things better than C's malloc/free and C++ new/delete, in that it can coalesce (sp?) objects around to make bigger holes, plus it can potentially free up more memory than the programmer is aware of. Nate 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?199808072250.QAA22022>