#Garbage collection
7 messages in this thread
What!? No one is interested in a garbage-collecting memory allocation package
for C and C++ (apparently only for SAS compilers)? Maybe it's because I posted
the message in the General Programming section, or I wasn't clear that it is
for C and C++ programs?
Oh, well. If anyone is interested, it can be ftp'd from parcftp.xerox.com,
file /pub/gc/gc.tar.Z, or ftp://parcftp.xerox.com/pub/gc/gc.tar.Z. It seems to
work well. I blythly (sp?) replaced malloc and realloc in a program on my unix
box at work with GC_malloc and GC_realloc, and commented out all of the free
calls, and it seems to work fine. (Actually, something went wrong, but the
author found the bug.) The only problem I read of in the Amiga port was that
it knows nothing about the difference between chip and fast memory. Probably it
only deals with fast memory, but I would think most of you don't build complex
dynamic data structures that need chip memory.
Clay
>> … no one is interested in a garbage-collecting memory allocation …
Clay,
well, in new programming projects, I tend to use pooled memory allocation using
the LibAllocPooled() routine (et al) from AmigaLib V 40.14.
Unfortunately, there is very little request for new profitable projects on the
Amiga in the moment.
– wkc – … via AP from Hamburg, Germany
Hi, Werner,
>>well, in new programming projects, I tend to use pooled memory allocation
using the LibAllocPooled() routine (et al) from AmigaLib V 40.14.<<
I only have the RKM manuals, so I don't know about allocPooled, etc. Do they
release memory automatically?
The advantage of garbage collecting allocators is that you don't have to worry
about freeing things. With complex dynamic data structures, it can be
difficult to decide on and stick to a discipline that assigns responsibility
for freeing memory to the appropriate functions. With garbage collection, you
just stop using the block of memory. The lack of a pointer to an allocated
block of memory will result in the block being freed when the collection code
is run. You can concentrate on other aspects of coding. (Perhaps I'm just a
sloppy programmer. 🙂
I assume the Amiga port of the garbage collector has some means of freeing
everything remaining when the program terminates, perhaps by hooking them into
the task structure at whatever that field is.
>>Unfortunately, there is very little request for new profitable projects on
the Amiga in the moment.<<
Do you mean people aren't interested because they can't sell their programs?
Is nobody programming for the Amiga?
Clay
>The advantage of garbage collecting allocators is that you don't have to worry
>about freeing things. With complex dynamic data structures, it can be
>difficult to decide on and stick to a discipline that assigns responsibility
>for freeing memory to the appropriate functions. With garbage collection, you
>just stop using the block of memory. The lack of a pointer to an allocated
>block of memory will result in the block being freed when the collection code
>is run. You can concentrate on other aspects of coding. (Perhaps I'm just a
>sloppy programmer. 🙂
Just for the sake of discussion, that same advantage can be a disadvantage.
As with everything, it depends upon what you are trying to do and is not
100% to allow you to concentrate on other aspects of coding. That is to
say, for something it can indeed free you "from the concern." On others,
this freedom can be quite intrusive. As such, as with everything, it should
be used as deemed appropriate.
>I assume the Amiga port of the garbage collector has some means of freeing
>everything remaining when the program terminates, perhaps by hooking them into
>the task structure at whatever that field is.
Probably, do not doubt its "calculated" and/or even explicitly invoked.
>Do you mean people aren't interested because they can't sell their programs?
>Is nobody programming for the Amiga?
Enough people have put it to rest and seems to be slowly and surely
more and more. This is no real suprise.
>>Just for the sake of discussion, that same advantage can be a disadvantage.
As with everything, it depends upon what you are trying to do and is not 100%
to allow you to concentrate on other aspects of coding. That is to say, for
something it can indeed free you "from the concern." On others, this freedom
can be quite intrusive. As such, as with everything, it should be used as
deemed appropriate.<<
I see, sort of. I have experience with at least one program that I wrote, in
which deciding how to free things was a major problem (at least, for me).
Garbage collection would have made that task much easier. Since I don't have
much experience with garbage collecting allocators, I don't really know what
trouble they can cause. I can imagine that one might occasionally have to
worry about zeroing a pointer to make sure something is freed (may as well free
it explicitly).
The allocation package I mentioned also has variants on plain malloc, and
having to think about which to use might be a problem. "GC_malloc_atomic"
allocates memory in which you promise not to store any pointers to other
allocated memory, so that the collector doesn't have to look there.
There is also "GC_malloc_ignore_off_page," which is intended for large blocks
of memory. Your program is supposed to keep a pointer to someplace in the
first 256 bytes, so that the collector won't worry about pointers into the rest
of the block. Since the collector just searches all known variables (the
stack, static variables, and allocated memory pointed to from there), it can
find accidental pointers into a block of memory and keep it, incorrectly. This
version of malloc avoids a lot of that. Apparently, you need to declare a
pointer to such a block as a "volatile", to keep optimizers from mucking it up
somehow. Clearly this is something we don't have to think about with the usual
versions of malloc, et al.
>>Enough people have put it to rest and seems to be slowly and surely more and
more. This is no real suprise.<<
It's understandable, but I'd rather not believe it.
Did I mention the C++ interface?
Clay
Clay,
>> I only have the RKM manuals, so I don't know about allocPooled, etc.
Pooled memory allocation has been introduced into the system software since OS
3.0 (V 39). It's part of the exec.library in ROM.
To gain downwards compatibility to OS 1.3 and 2.X, C= put the code into the
amiga.lib as well. The functions put in the amiga.lib will first check what OS
they are running on, then jumping to ROM Code if run under OS 3.0 or better,
else using the code linked in with amiga.lib.
.>> Do they release memory automatically?
Well, sort of.
The idea with pooled memory is, not to allocate/deallocate every little chunk
of memory you need. You rather preallocate a big pool of memory from the
system, and let your application allocate/deallocate from that pool. If the
pool runs out of space, another big pool is allocated.
So you may only release the pools you got from the system when your program
exits.
>> Do you mean people aren't interested because they can't sell their .>>
programs?
Well, I don't develop programs to be directly thrown on the marketplace. I
rather do my programming for special projects the customer asks for. As an
example, I developed pressure vessel designing software for one client. For
another customer, I did some accounting software – because all they found on
the market was overpowered and complicated to use, but did't cover some simple
add-ons they needed.
.>> Is nobody programming for the Amiga?
Sure there are people programming for the Amiga. But you can't make a life of
it by doing so any more.
<I hope my English wasn't too bad…>
– wkc – … via AP from Hamburg, Germany
Your English is excellent. Now, take my sentence "Is nobody…", which sounds
bad to me. 🙂
Clay