Comment 1 for bug 1903413

One reason for this state of matters is because the STANDARD-CLASSOID for SLOT-OBJECT holds possibly permanent strong references to all of its subclasses.

For instance, in the below example after creating some anonymous classes, the value of SUBCLASSES in that classoid is a non-weak hash table that holds 12157 elements, therefore keeping all the classoids and their layouts live and contributing to the aforementioned memory leak.

---------------------------

CL-USER> (let* ((slot-object-class (find-class 'sb-pcl::slot-object))
                (slot-object-wrapper (slot-value slot-object-class 'sb-pcl::wrapper))
                (slot-object-classoid (slot-value slot-object-wrapper 'sb-pcl::classoid)))
           (swank:inspect-in-emacs slot-object-classoid))

#<SB-KERNEL:STANDARD-CLASSOID {1000052D03}>
--------------------
The object is a STRUCTURE-OBJECT of type SB-KERNEL:STANDARD-CLASSOID.
%BITS: 1387484958
NAME: SB-PCL::SLOT-OBJECT
LAYOUT: #<SB-KERNEL:LAYOUT for SB-PCL::SLOT-OBJECT {50217103}>
STATE: NIL
DIRECT-SUPERCLASSES: NIL
SOURCE-LOCATION: NIL
SUBCLASSES: #<HASH-TABLE :TEST EQ :HASH-FUNCTION #<FUNCTION SB-KERNEL:TYPE-HASH-VALUE> :COUNT 12157 {1000250603}>
PCL-CLASS: #<SB-PCL::SLOT-CLASS SB-PCL::SLOT-OBJECT>
OLD-LAYOUTS: NIL