Apparent memory leak on SBCL
Created by: genworks
This is possibly related to portable allegroserve.
Bringing up a standard Gendl web page such as
and drawing a robot will consume a large amount of heap, simply reloading this page several times will exhaust the SBCL heap. On Allegro CL it is using just a fraction of the memory and garbage collection always seems to bring the used oldspace back to baseline.
So there is some kind of memory leak going on with the SBCL platform. I need to develop a more standardized way of testing for this but in the meantime if anyone has any clues, I will be very interested!
Note that you can clear all web sessions with
(gwl:clear-all-instances)
So, in theory you should be able to make unlimited web pages and clear them with (gwl:clear-all-instances), and garbage collection should bring things back to baseline.
EDIT: A programmatic way to replicate this is:
(in-package :gdl-user) (dotimes (n 1000) (net.aserve.client:do-http-request "http://localhost:9000/newsite") (gwl:clear-all-instances))
You will exhaust your heap for sure. If you want to stop before exhausting the heap just do it 50 or 100 instead of 1000 times. Then perhaps it will be possible to examine the heap and see what is taking up all the space.
Imported comments:
By genworks on 2012-10-11 23:19:17 UTC
This is apparently fixed now. The issue was our implementation of glisp:make-weak-hash-table as defined in
gdl/base/common/genworks.lisp
For SBCL we were using
(make-hash-table :weakness :key-or-value)
and we really need the entries to disappear when only the value becomes garbage, so the correct option is:
(make-hash-table :weakness :key-and-value)
I am committing the fix now; it should make it into the October 2012 Quicklisp release.