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

[Erik Huelsmann]

On Thu, Jan 27, 2011 at 9:26 PM, Blake McBride <blake at mcbride.name> wrote:
> 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!

You're welcome. We hope that our support is of mutual benefit: I'm
sure the issues you have experienced so far will be or would have been
experienced in the future by others too. Your continued efforts help
shake up ABCL for better large-scale systems development. I hope I'm
speaking for the other developers when I say I appreciate the trust
you put in us by embarking on this effort.

By the way, you've seen little activity on this issue because I'm
trying to clean up some CLOS code to address an issue reported by Alan
Ruttenberg in december. There were two ways to solve his report; one
by quick hacking, the other by diving in deep and trying to use the
solution to move our CLOS a bit closer to the AMOP spec. If you know
me, you'll know I chose the latter :-)  Once Alan's issue is resolved,
I'll follow up with more work on the issue this thread is about.

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

Well, strictly speaking, it's only the *name* of the function or class
which is located in a package: they're both tied to symbols in a
package indeed.

There is a big difference between functions and classes though:
classes are part of a hierarchical structure of classes which all
store references to each other through slot values in their
metaclasses. One of the properties of the graph of classes is that
it's rooted in the CL package (through the classes T, STANDARD-CLASS
and STANDARD-OBJECT). When a package is deleted, the class structure
(not its name) will still be referenced from the "other" classes in
the class-graph.

Although functions are part of a graph of cross references too, the
graph doesn't go back to any packages which will never be deleted:
while packages will be using the CL package, the CL package will never
incorporate function calls to user-defined functions. This doesn't
happen in your situation, but if you have 2 packages which cross
reference each other, it could be that part of a package which is
being deleted can't be cleaned yet, because it's still referenced by
the "other" package.

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

Right. That's why I started the thread. Of course if you have intimite
knowledge of an implementation, you could figure out what all needs to
be removed in order to disentangle the graph. I'm sure most users
aren't in such a position.

Possibly, it would make sense to create a facility which allows
execution of "cleanup functions" upon package deletion. Such a
facility could then be used to "disentangle" the web around the class,
causing the class to be collected as soon as the package is deleted
and with it the symbol naming the class. That would achieve roughly
what you describe above.


Regards,


Erik.