[armedbear-devel] [RFC] How to better support disposal of class objects

[Blake McBride]

Greetings,

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
really appreciated!

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
explicitly deleted.

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.

Thanks.

Blake McBride




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?
>
>
> Bye,
>
>
> Erik.
>
> _______________________________________________
> armedbear-devel mailing list
> armedbear-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20110127/3fd5b987/attachment.html>