Greetings,<div><br></div><div>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!</div><div><br></div><div>

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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Thanks.</div><div><br></div><div>Blake McBride</div><div><br></div><div><br></div><div><br><br><div class="gmail_quote">On Thu, Jan 27, 2011 at 1:19 PM, Erik Huelsmann <span dir="ltr"><<a href="mailto:ehuels@gmail.com" target="_blank">ehuels@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">To prevent any confusion beforehand: The mail below talks about class<br>
objects, objects which store class definitions, not the actual<br>
instances of those classes, which use those class definitions and<br>
store class-allocated or instance values.<br>
<br>
We have fixed a few bugs where memory would be allocated during<br>
(package creation or) FASL loading, but would not be freed upon<br>
package deletion. That was an issue because it's an explicit use-case<br>
for Blake.<br>
<br>
Last weekend I came up with another "leak" in ABCL. The word "leak" is<br>
between quotes, because depending on how you look at it, not all of it<br>
may technically be leaky.<br>
<br>
<br>
My point: it's easy to create a class; simply use a DEFCLASS form.<br>
However, unlike package creation, which can be "undone" through<br>
DELETE-PACKAGE, there's no DELETE-CLASS function to undo the result of<br>
a DEFCLASS.<br>
<br>
I started to think about supporting the use-case of deleting a class.<br>
Digging around in our implementation, I found there are several<br>
reasons why a class won't be automatically cleaned up when the package<br>
containing its naming symbol is deleted:<br>
<br>
1. Every parent maintains a list of subclasses<br>
    The list contains class objects, meaning that the actual class-object is<br>
    referenced in this list and for that reason can't be GC-ed<br>
2. Every generic function maintains a list of specializing methods<br>
    The methods in the list refer to the dispatch types,<br>
    meaning that the class-objects are strongly referenced from there too<br>
3. Our FIND-CLASS implementation contains strong references to both<br>
    the naming symbols as well as the class-objects.<br>
4. Our implementation uses a cache to speed up the calls to generic<br>
    functions. This cache uses strong references too.<br>
<br>
<br>
The issue in item (3) can be solved (relatively) easy by developing a<br>
weak hash table which contains both weak keys and values. This hash<br>
table could even be made available as regular Lisp objects.<br>
<br>
Item (4) currently uses an explicitly specialized hash table<br>
implemented on the Java side. The hash table could be adapted to use<br>
weak references as well - the effort wouldn't be as generally usable,<br>
but that's just tough luck.<br>
<br>
<br>
Items (1) and (2) are something to think about though: Is it wise to<br>
implement a function which removes the methods and the class from its<br>
parent? What if the class itself has direct subclasses? Do we signal<br>
an error? Do we provide a parameter forcing the deletion of a whole<br>
tree? Or maybe we should just document how potential users of our CLOS<br>
should proceed if they have the intention to do this, since it won't<br>
be portable anyway?<br>
<br>
<br>
Myself, I'm currently contemplating "just document" on one hand and<br>
"do whatever we can, even if they're whole trees" on the other...<br>
<br>
<br>
What do other people think?<br>
<br>
<br>
Bye,<br>
<br>
<br>
Erik.<br>
<br>
_______________________________________________<br>
armedbear-devel mailing list<br>
<a href="mailto:armedbear-devel@common-lisp.net" target="_blank">armedbear-devel@common-lisp.net</a><br>
<a href="http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel" target="_blank">http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel</a><br>
</blockquote></div><br></div>