[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
GNUStep-base with gc=yes
GNUStep-base with gc=yes
Sat, 4 May 2002 04:24:25 -0400
Well - basically, it just does not compile at all with gc=yes in version
1.3.0 and 1.3.2. I take it noone is working on, or even testing, this
capability anymore? That's a shame... Anyways, the fix is fairly easy.
In NSData.m, replace all mentions of NSAtomicMallocZone() with
GSAtomicMallocZone. After that change, it at least compiles, and appears
to achieve basic functionality, as well.
However, it does look like there are problems. I'm thinking in
particular of places that keep a pointer to memory after its been
"released", thus preventing the GC from actually freeing the memory. For
example, in GSIMap.h:
static INLINE void
GSIMapFreeNode(GSIMapTable map, GSIMapNode node)
node->nextInMap = map->freeNodes;
map->freeNodes = node;
This does not set node->key = 0 and node->value = 0, so in a GC world,
the objects pointed to by key and value will not be freed until the
"free node" is reused. My proposed solution would be to add something
#if GSI_MAP_KTYPES & GSUNION_OBJ
node->key.obj = nil;
#if GSI_MAP_KTYPES & GSUNION_PTR
node->key.ptr = 0;
#if GSI_MAP_VTYPES & GSUNION_OBJ
node->value.obj = nil;
#if GSI_MAP_VTYPES & GSUNION_PTR
node->value.ptr = 0;
to GSIMapCleanMap and GSIMapFreeNode.
A similar problem occurs in GSArray.c in remove*Object*. After moving
all the elements down one position in the array, the last element (which
is now unused) gets left set to what it previously was. It should be set
to 0. Otherwise the object it points to will never be collected. This is
especially a problem when doing removeAllElements, as that simply calls
removeLastElement repeatedly, thus ensuring the actual array data is
never changed, and thus none of the objects pointed to by the array are
released until the array fills back up again. I would add the line:
_contents_array[_count] = 0;
into all the remove functions.
I'm sure there are other places that do similar things as well, as I
have not gone through all the code. I'm somewhat disappointed that I'm
seemingly the only person interested in a GC'd ObjC runtime as it seems
like a very good idea. Ah well.
Also, there's a bunch of places that could be cleaned up that use [obj
release] and [obj retain] (some with "#ifndef GS_WITH_GC" around them)
instead of the RELEASE and RETAIN macros.
Finally, does anyone know why NSObject +requiresTypedMemory exists and
always returns NO? I would think it would be a good idea to always
allocate objects in typed memory?
|[Prev in Thread]
||[Next in Thread]|
- GNUStep-base with gc=yes,
James Knight <=