[armedbear-devel] [RFC] How to better support disposal of class objects
blake at mcbride.name
Thu Jan 27 20:26:47 UTC 2011
First of all, thanks so much for help with this issue. I would not have
been able to use ABCL without the fantastic support I've gotten. It is
I did a little checking and CL does seem to localize class definitions to
packages as it does for regular functions. Not too surprising. So, it does
make sense for a class definition to be totally eradicated when a package is
The serious down side of not eliminating a class definition is that if a
package is load, deleted, and reloaded many times, the act of defining the
same class (presumably in the same package name but will actually be
creating a new package structure) causes (in essence) a memory leak.
On Thu, Jan 27, 2011 at 1:19 PM, Erik Huelsmann <ehuels at gmail.com> wrote:
> To prevent any confusion beforehand: The mail below talks about class
> objects, objects which store class definitions, not the actual
> instances of those classes, which use those class definitions and
> store class-allocated or instance values.
> We have fixed a few bugs where memory would be allocated during
> (package creation or) FASL loading, but would not be freed upon
> package deletion. That was an issue because it's an explicit use-case
> for Blake.
> Last weekend I came up with another "leak" in ABCL. The word "leak" is
> between quotes, because depending on how you look at it, not all of it
> may technically be leaky.
> My point: it's easy to create a class; simply use a DEFCLASS form.
> However, unlike package creation, which can be "undone" through
> DELETE-PACKAGE, there's no DELETE-CLASS function to undo the result of
> a DEFCLASS.
> I started to think about supporting the use-case of deleting a class.
> Digging around in our implementation, I found there are several
> reasons why a class won't be automatically cleaned up when the package
> containing its naming symbol is deleted:
> 1. Every parent maintains a list of subclasses
> The list contains class objects, meaning that the actual class-object is
> referenced in this list and for that reason can't be GC-ed
> 2. Every generic function maintains a list of specializing methods
> The methods in the list refer to the dispatch types,
> meaning that the class-objects are strongly referenced from there too
> 3. Our FIND-CLASS implementation contains strong references to both
> the naming symbols as well as the class-objects.
> 4. Our implementation uses a cache to speed up the calls to generic
> functions. This cache uses strong references too.
> The issue in item (3) can be solved (relatively) easy by developing a
> weak hash table which contains both weak keys and values. This hash
> table could even be made available as regular Lisp objects.
> Item (4) currently uses an explicitly specialized hash table
> implemented on the Java side. The hash table could be adapted to use
> weak references as well - the effort wouldn't be as generally usable,
> but that's just tough luck.
> Items (1) and (2) are something to think about though: Is it wise to
> implement a function which removes the methods and the class from its
> parent? What if the class itself has direct subclasses? Do we signal
> an error? Do we provide a parameter forcing the deletion of a whole
> tree? Or maybe we should just document how potential users of our CLOS
> should proceed if they have the intention to do this, since it won't
> be portable anyway?
> Myself, I'm currently contemplating "just document" on one hand and
> "do whatever we can, even if they're whole trees" on the other...
> What do other people think?
> armedbear-devel mailing list
> armedbear-devel at common-lisp.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the armedbear-devel