<div dir="ltr">Read the Ungar paper I linked. It does exactly what you're describing, and also gives a good overview of different garbage collection strategies. The idea is in part to do small GCs very often, and avoid full GC until the user is idle (imagine sitting at a stop light.) And I said a *fraction* of a second, not a whole second. This paper was written in the 90s and referred to a system which also used virtual memory. Nix the virtual memory, go with flash for storage, use a generation scavenging garbage collector, and try profiling that setup *today.* I think -- of course I don't know, because I haven't done the profiling -- that you'll have a latency much lower than the average nimrod texting on the road has.<div>
<br></div><div>Eliot is working on a new object memory for Cog called Spur, which I understand will dramatically reduce the amount of time the VM spends in GC; since it isn't causing huge pauses *now,* and it will get *much* better in the near future, I really don't think that GC is something to worry about.</div>
<div><br></div><div>And yes, C and C++ are *very* dangerous languages because they're semantically the same as macro'd machine code. This means (for example) that one can accidentally write words of data past the end of an array: this is called a buffer overrun. If the address of the first thing after the end of the array happens to be a function which will get called in the future, and the data being written is supplied by an external party (like a user or bot) it is possible for a bad actor to overwrite part of that function and inject machine code into your application. If your application is running as a privileged user, it's trivial to take complete control of the machine that it runs on, and if not, there's still plenty of opportunities for privilege escalation.</div>
<div><br></div><div>Smalltalk doesn't have this problem because it doesn't expose raw pointers to the programmer. Arrays are bounds checked. All memory access -- in fact, all hardware access -- is managed by a well-maintained virtual machine. And a million and one other things that eliminate some serious programmer errors. C and C++, OTOH, are rather like riding a horse naked without a saddle. You might get where you're going just a hair faster than if you had gotten dressed and put the saddle on first, sure, but it's liable to hurt a lot afterwards.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Dec 18, 2013 at 6:37 AM, Kirk Fraser <span dir="ltr"><<a href="mailto:overcomer.man@gmail.com" target="_blank">overcomer.man@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks for the discussion. I didn't know C++ was so bad. Is there any negatives about Python? <div>
<br></div><div>On government, I think ADA is about as dead as Cobol. They aren't requiring it in the DARPA Robotics Challenge. But I did see on comp.lang.Smalltalk where one huge government project in Smalltalk failed because they couldn't stop an unwanted ship from appearing in a simulation or something like that. So they went to C.</div>
<div><br></div><div>On a vehicle, the worst times I can imagine for a GC of even one second is just before a decision is needed to round a corner or stop. Is there a way to fan out GC's so they are more frequent but less time consuming? Perhaps a millisecond every second - let's see at 60 mph that would be 316800 feet per hour, 88 feet per second, 0.088 feet per millisecond or 1.056 inches. The Google car shoots for 1 cm accuracy - 1 in. is close enough. So a garbage collection of one second means 88 feet off course but a millisecond would work. </div>
<span class="HOEnZb"><font color="#888888">
<div><div><br></div>-- <br><div dir="ltr"><div>Kirk W. Fraser</div>
<div><a href="http://freetom.info/TrueChurch" target="_blank">http://freetom.info/TrueChurch</a> - Replace the fraud churches with the true church.</div>
<div><a href="http://freetom.info/" target="_blank">http://freetom.info</a> - Example of False Justice common in America</div></div>
</div></font></span></div>
<br>_______________________________________________<br>
Cuis mailing list<br>
<a href="mailto:Cuis@jvuletich.org">Cuis@jvuletich.org</a><br>
<a href="http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org" target="_blank">http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org</a><br>
<br></blockquote></div><br></div>