On Tue, 8 Feb 2011 23:17:04 +0100 Juan Jose Garcia-Ripoll <juanjose.garciarip...@googlemail.com> wrote:
> The first one is that finalizers are not immediately called during garbage > collection. That would be insane, because arbitrary lisp code can only be > invoked when memory allocation is possible. Instead, a garbage collection > may trigger a finalization process which first revives the object, then, > possibly in the next GC cycle, finalizes it and finally, being zeroed > memory, it gets deallocated. This is fine > Second, ecl_dealloc() is just a hint to the garbage collector. Memory may or > may not be marked as unused immediately, but even then, finalization will > not be called until the GC cycle process I mentioned before happens. In > general this is true for all garbage collectors: finalization is associated > to GC not to "deallocation", an operation which is too costly if carried on > fully. > > So if you want deterministic finalization, first finalize the object and > _then_ deallocate it. Thanks a lot. Indeed I've seen these limitations in other GC languages although I wasn't sure in the case of ECL+boehm-gc. So I won't rely on this and will simply provide a function to reset/clear an object in my library. -- Matt ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
