Re: Larry Wall, on Tcl

Alan Anderson wrote:
I don't want to be contentious. I'm not arguing merely for the sake of arguing.

I understand. That's why I'm still answering *you*. ;-)

> I honestly want to understand what's so great about garbage
collection, and what it does to make things easier for me as a programmer. So far, I have seen examples that are obviously invented to showcase the kind of programming errors that GC can clean up after, and I've seen analogies that fail to address the question of what makes it any easier to rely on GC.

The problem is that in small systems, resources are easy to keep track of. In large systems, they're not, due to multiple layers of abstraction between where items are allocated and where they're used.

How easy would C be if every call to "free" had to indicate what line of source code the corresponding "malloc" was on? Sure, if each chunk of memory allocated was only freed in one place, it wouldn't be too painful. But get a library where the person writing the library wants to change the code to allocate things in multiple places to deal with new resources, which perhaps the application programmer isn't even dealing with, and suddenly it gets really messy.

Yes, virtual memory *does* mask the bug of a program allocating too much. It keeps the bug from being noticed unless the subsystem using slow physical memory to back the virtual memory is overwhelmed.

Unless that never happens.

Note: the file's space won't get reused until *I* delete it. There's an explicit action on my part that separates "in use" from "not in use".

As there is in a GC system. When you make the data no longer accessible within the semantics of the language you're using, it can be collected. For example, when you overwrite the last pointer to the block of memory, it can be freed automatically.

Note that when you *explicitly* free the file, another program that's still expecting it to be there crashes. If you for some reason don't free the file (say, your process core dumps, or is externally killed), your temp file never ever goes away. Both of those are prevented by garbage collection (altho a garbage collection that works with files is pretty rare - this is just an example).

None of this helps me understand how a garbage collector can know for certain that my program is done with something _unless I say so_.

If you have a chunk of memory to which no pointer points, it's garbage. For this to work, you have to be working at a level above that of the raw bytes of the machine language.

far as I can tell, I'm still tasked with the "bookkeeping" of when I'm using it and when I'm not. I still have to say "done using this chunk of memory" at some point, don't I?

When you overwrite the last pointer, the memory is freed.

In the Tcl world, when there's no longer any string anywhere in the program that contains "file5", then the fifth file handle gets closed. So

set x [open /tmp/one]
set y [open /tmp/two]
set x $y
would close /tmp/one on the third line.

> If the system is to know accurately whether or not
the resource is still in use, there's got to be something specific I'm doing when I'm done with it.
Nope. That's the point.

{ char * x = malloc(10000); exit(0); }

What did you have to do with the malloc'ed space to return it to the system? Does it change depending on how much space you malloc'ed?

This is another trick question, right? This example explicitly returns control of *everything* to the system by calling exit(). Hiding it on the same line as the malloc() doesn't make it go away.

But how does the kernel clean up? It's keeping track. Somewhere in the kernel is a pointer, indexed by process ID, of the list of all the pages that process can get to. The kernel frees all the pages that that process, and *only* that process, can get to.

The GC subsystem does it the same way. It has a list of all the chunks of memory, just like malloc() uses to avoid reallocating multiple chunks of memory. The GC runs thru that list and frees any chunks you don't have any pointers to.

just seems wrong to take a chunk of memory and not give it back explicitly when I'm done with it.
It's what you're used to. What do you do to explicitly free up registers in your C code when you're done with them? How does your code know when it's OK to reuse AX, and that you don't have something you need in there you'll use 10 instructions later?

You're talking about things that don't exist in my universe. My C code doesn't use registers, and I suspect neither does yours. The compiled machine instructions to implement that code on a specific target CPU will perhaps use the AX register, but C code cares nothing about such details.

Ding ding ding! That's the point. You don't need to worry about when your registers are free, any more than with GC you worry about when your memory is free. It's an entirely different level of abstraction. You don't tell the GC the memory is free, any more than you tell the C code that the register is free. You never see the GC in operation, as such. If you do, you're doing the same level of optimizations that using the "register" keyword implies.

--
Darren New / San Diego, CA, USA (PST)
It's not feature creep if you put it
at the end and adjust the release date.
.

Relevant Pages

  • Re: Larry Wall, on Tcl
    ... I honestly want to understand what's so great about garbage ... It stops it from being a bug. ... virtual memory *does* mask the bug of a program allocating too ... doesn't use registers, and I suspect neither does yours. ...
    (comp.lang.tcl)
  • Re: ICFP Contest
    ... This the BALANCE machine puzzle concocted by Y. Yang. ... Each of the source and destination registers is an indirect register. ... stored in the memory location indicated by the current contents of D. ... industry's leading programmer certification programs. ...
    (comp.lang.forth)
  • Re: ICFP Contest
    ... This the BALANCE machine puzzle concocted by Y. Yang. ... Each of the source and destination registers is an indirect register. ... stored in the memory location indicated by the current contents of D. ... industry's leading programmer certification programs. ...
    (comp.lang.forth)
  • Re: [Vuln-Dev Challenge] - VulnDev1.c Summary
    ... meaning the chunk is allocated with mmap. ... turn calls munmap on an invalid memory address. ... > the Doug Lea algorithm as well has heap-based exploitation methods ... > the forward chunk, in our case buf2, is free. ...
    (Vuln-Dev)
  • The Malloc Maleficarum
    ... Glibc Malloc Exploitation Techniques ... the exploitation of overflowed dynamic memory chunks on Linux. ... I have the House of Prime. ... a malloc chunk. ...
    (Bugtraq)