On Wed, Oct 02, 2002 at 03:46:33PM +0200, Leopold Toetsch wrote:
> Nicholas Clark wrote:
>
> >On Wed, Oct 02, 2002 at 02:01:48PM +0200, Leopold Toetsch wrote:
> >>+ if (buffer->bufstart && !(buffer->flags &
> >>+ (BUFFER_COW_FLAG|BUFFER_external_FLAG))) {
> >>+ free(buffer->bufstart);
> >>+ }
>
> >The article doesn't mention garbage collection at all, and neither your
> >remarks nor your patch explains how it is now done. Is all garbage being
> >collected via that one free(buffer->bufstart); in the patch above?
> >I'm confused, and would appreciate hints about how to become less confused.
> What about reading this page and downloading the file ;-)
I did. I thought that GC referred to the idea of making (in C terms) free()
a no-op, and arranging to automatically free() any memory that the allocator
knows has leaked. And yet all I saw in your patch *was* a call to free.
<digression>
Which in C terms scares me, as *how* can the allocator know for sure?
Sure it can stack walk, and probe all the CPU registers for pointers to buffers,
but there are defined C behaviours you can do (such as storing only a pointer
somewhere into your buffer at fixed known-to-you offset.
Or storing your only pointer somewhere weird, such as mmaped memory (or shared
memory, or somewhere not in the stack or heap), or worse still in a file,
database, or somewhere outside your memory space. It's not leaked - your
pathological but correct program knows how to get the pointer back
</digression>
On Wed, Oct 02, 2002 at 04:01:02PM +0200, Leopold Toetsch wrote:
> Jason Gloudon wrote:
>
> >On Wed, Oct 02, 2002 at 02:01:48PM +0200, Leopold Toetsch wrote:
>
>
> >Whatever source you are using cannot be the original Lea malloc, since it
> >does
> >not do garbage collection.
>
>
> * VERSION 2.7.2 Sat Aug 17 09:07:30 2002 Doug Lea (dl at gee)
>
> There seems to be no need for real GC, since fragmentation is ~3% or lower.
Jason's thoughts echo mine. However, I see the confusion about what is meant
by GC. He and I are thinking about malloc/realloc/free level garbage collection.
On Wed, Oct 02, 2002 at 07:46:07PM +0200, Leopold Toetsch wrote:
> Dan Sugalski wrote:
> >Since all pool memory has to be anchored with buffers, and allocation
> >has to use buffers, the GC issues get subsumed into DOD runs, which is
> >OK--memory allocation, reallocation, and freeing will all be actively
> >traceable so we shouldn't leak, at least if we don't leak buffers.
>
>
> Yes, this were my thoughts WRT GC
So we only need at parrot level to garbage collect our buffers, as the only
thing we allocate and hand out to code is buffers? If so, this explains my
confusion.
> Yes, when our interface is malloc/realloc/free, any allocator could be
> plugged in.
Which is what I was thinking when I left work. If we're only allocating,
tracking and garbage collecting buffers, what stops us having the option
of getting and returning memory from the system's malloc()?
That way we could offer a smaller footprint parrot for tight platforms by
not providing our own allocator code. [With the assumption that our own code
is faster for our needs than system malloc, but let's prove that :-) And
anyone benchmarking this please try on HP/UX. It has an interesting malloc
that seems to cope with pathologically bad code loops that do repeated
realloc()s one thing bigger each time. I'd love to see the source to that,
because I suspect that this choice of behaviour and the performance it gave
to inefficiently written code made HP the sale to the firm I worked out.
Nicholas Clark
--
Even better than the real thing: http://nms-cgi.sourceforge.net/
