bug-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

GNUStep-base with gc=yes


From: James Knight
Subject: GNUStep-base with gc=yes
Date: 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)
{
  GSI_MAP_RELEASE_KEY(map, node->key);
#if GSI_MAP_HAS_VALUE
  GSI_MAP_RELEASE_VAL(map, node->value);
#endif
  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 like:
#if GSI_MAP_KTYPES & GSUNION_OBJ
node->key.obj = nil;
#endif
#if  GSI_MAP_KTYPES & GSUNION_PTR
node->key.ptr = 0;
#endif
#if GSI_MAP_HAS_VALUE
#if GSI_MAP_VTYPES & GSUNION_OBJ
node->value.obj = nil;
#endif
#if  GSI_MAP_VTYPES & GSUNION_PTR
node->value.ptr = 0;
#endif
#endif

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?
James




reply via email to

[Prev in Thread] Current Thread [Next in Thread]