Garbage Collection

[rhoge]

Recent versions of NeuroLens have been built using garbage collection, which is just a compiler flag. As you know, if this option is selected then all retain/release invocations are ignored and dealloc is never called (finalize is used instead).

Older versions of NeuroLens suffered from retain cycle problems that originated in the relationship between the dataset window, the document and the window controller (some people think that this kind of thing is why Apple introduced GC in the first place). The retain cycle problem is the reason for the checkbox in NeuroLens under the "Dev" tab in preferences to force a cleanup of image data when a datasset is closed. Under GC this should no longer be needed.

Although GC sounds (and is) nice, there are a number of programming practices that used to be ok but which can now cause problems (mostly crashes, but also memory leaks). I'm starting this thread as a place to list such issues.

Rick

[rhoge]

On thing that caused crashes in NeuroLens after the switch to GC was methods (or functions) that return a pointer to memory allocated using an autoreleased NSMutableData:

-(float*)badMethodForGC {

  float *buffer = (float*)[[NSMutableData dataWithLength:100] mutableBytes]; // Would be autoreleased in non-GC

  return buffer; // In non-GC, buffer could be used until end of current event loop, when autorelease pool is released

}

Under GC, the collector does not know that 'buffer' is a reference to some bytes in the NSMutableData object. It will free the data at the bottom of the above method (thinking the scope where the data can be used is finished), and any subsequent use of the pointer 'buffer' (which used to be ok) will cause a crash.

Under GC, the correct way to do this is now:

-(__strong float*)goodMethodForGC {

  __strong float *buffer = (float*)NSAllocateCollectable(100,0); // Like malloc for GC

  return buffer;

}

Note that the second parameter in NSAllocateCollectable is a flag indicating whether the GC should scan that memory for pointers referencing other collectable data. As far as I can tell, if you are just going to use the chunk of data to contain arbitrary data (pixel values, etc.) the flag can be zero. An example where you would set the flag to a value of NSScannedOption is when you will use the data to contain an array of pointers (e.g. the return value will be float**). This was causing the crash in the Volume Registration action after the port to Leopard.

Rick

[Arnaud]

Hi Rick,

Thanks for posting the details in the forum on how to do implement GC correctly. I had that exact same error that you described while trying to allocate an NSMutableData in the plugin "run" method.
It seems like large datasets (>~700Mb) aren't any longer supported by NSMutableData. The new syntax using NSAllocateCollective seems to work fine for me at least for the allocation and processing parts. However, this causes a problem with the current implementation of the plugin framework since the MyVolume:configWithData method takes an NSMutableData as first argument.
I've been looking for a more elegant workaround than reimplementing the configWithData method. Any thought would be greatly appreciated.
Cheers,
Arnaud

[Arnaud]

Building against older versions of the NLPlugin and NLMatrix frameworks seems to be working fine. It will do the trick for the time being.