Steel Bank Common Lisp

Fredrik Tolf <fredrik@...> writes:

> I've tried creating a class in a couple of ways that I thought would work, 
> and then installing a finalizer function on it to show if it were GC'd, 
> but I can't seem to get them to be GC'd whatever I do, even if I hack away 
> all the references I've been able to find, including the following 
> obviously ugly ways:
>
> (let ((test-class (defclass foo (transient) ())))
>    (finalize test-class #'(lambda () (print "foo")))
>    (setf (sb-kernel:classoid-cell-pcl-class (sb-kernel:find-classoid-cell 'foo)) nil)
>    (sb-mop:remove-direct-subclass (find-class 'transient) test-class))

Well, this seems to be nearly there: if I run

  (let ((c (let ((test-class (defclass foo (transient) ())))
             (finalize test-class #'(lambda () (print "foo")))
             (setf (sb-kernel:classoid-cell-pcl-class (sb-kernel:find-classoid-cell 'foo)) nil)
             (sb-mop:remove-direct-subclass (find-class 'transient) test-class))))
    (dotimes (i 3) 
      (gc :full t)) 
    (sb-vm::map-referencing-objects #'print :dynamic c))

then I get as output

  #<SB-KERNEL:STANDARD-CLASSOID FOO> 
  (#<STANDARD-CLASS FOO> (24 . #<CLOSURE # {100295C189}>)) 

The first of these is obvious, I guess: we'd need an extra
  (setf (sb-kernel:classoid-pcl-class (sb-kernel:find-classoid 'foo)) nil)
to remove the reference from the classoid (which raises the question of
why the classoid and the classoid-cell both need a reference...

The second is more problematic; I couldn't convince myself that it came
from a real reference, and MAP-REFERENCING-OBJECTS isn't reliable enough
to do a fine dissection (adding the clearing of CLASSOID-PCL-CLASS made
the other printed reference go away).  On the other hand, I wasn't
getting the finalization message printed either, so more investigation
is needed.

Cheers,

Christophe

On Sat, 29 Sep 2012, Christophe Rhodes wrote:
> sb-vm::map-referencing-objects

I didn't know of that function. That's quite a useful debugging tool. 
Thanks! :)

> The second is more problematic; I couldn't convince myself that it came
> from a real reference

Indeed; it makes me wonder if the compiler or some other even more basic 
part of SBCL keeps some kind of special reference to it, and makes me 
wonder if it's even possible to GC classes, and I'm not really competent 
enough in SBCL's internal to answer that question myself.

--

Fredrik Tolf

On 29 September 2012 19:09, Fredrik Tolf <fredrik@...> wrote:
> On Sat, 29 Sep 2012, Christophe Rhodes wrote:
>> sb-vm::map-referencing-objects

A caveat: it doesn't inspect closures or funcallable instances.

When someone has a moment, re-building it on top of
SB-INTROSPECT:MAP-ROOT would be good.

> Indeed; it makes me wonder if the compiler or some other even more basic
> part of SBCL keeps some kind of special reference to it, and makes me
> wonder if it's even possible to GC classes, and I'm not really competent
> enough in SBCL's internal to answer that question myself.

It should be possible, but it's a bit of a pain right now. Eg. if
you've called methods, their dispatch tables are going to hold
references to the class wrapper.

Cheers,

 -- Nikodemus

On Sun, 30 Sep 2012, Nikodemus Siivola wrote:
> On 29 September 2012 19:09, Fredrik Tolf <fredrik@...> wrote:
>> Indeed; it makes me wonder if the compiler or some other even more basic
>> part of SBCL keeps some kind of special reference to it, and makes me
>> wonder if it's even possible to GC classes, and I'm not really competent
>> enough in SBCL's internal to answer that question myself.
>
> It should be possible, but it's a bit of a pain right now. Eg. if
> you've called methods, their dispatch tables are going to hold
> references to the class wrapper.

Oh, I see; that seems like quite a bit of pain, indeed.

If I propose, then, such transient classes as a feature request instead, 
would that be taken seriously? :)

--

Fredrik Tolf

On 30 September 2012 21:09, Fredrik Tolf <fredrik@...> wrote:

>> It should be possible, but it's a bit of a pain right now. Eg. if
>> you've called methods, their dispatch tables are going to hold
>> references to the class wrapper.

I take this back, actually. It seems I misremembered: wrappers point
to classes only though classoids, so nuking references to classes in
classoids should be enough to take care of them. Old wrappers left
over should be harmless and will be dropped from the caches on their
own.

There might be another surprise someone inside PCL, but nothing overly
exciting, I think.

Cheers,

 -- Nikodemus

On Tuesday, September 25, 2012, wrote:

> I've been using macports to generate a threads image for MacOSX: sbcl
> @1.0.58_0+threads
>
> This seems to work ok, but I'm having a problem with saved images using up
> heap space.  If I save the image and run it on my machine, it will quickly
> fail, running out of heap.  If I save the image using :save-runtime-options
> T, it doesn't run out of heap space.


Saving runtime options saves any --dynamic-space-size you've set. Possibly
you're providing that in wrong part of the commandline when running the
app? You can check the size of the heap using (sb-ext:dynamic-space-size).

My machine is a dual core.  If I ship the image (the one saved using
> :save-runtime-options T) to a quad core, it again quickly runs out of heap
> space.

 No ideas here.

I'm using mcclim (latest as downloaded and installed using quicklisp), and
> I've been using threads, but my code should start no more than 2 threads,
> yet all 4 cores are getting used heavily when the interface is doing
> nothing but waiting for some heavy computing in my application to run (in
> no more than 2 threads that I'm starting explicitly).




  - n

>
>  Monitor (sb-thread:list-all-threads) to verify the number of threads?



-- 
Sent from a tablet, sorry about the top-post and sloppy editing.