Steel Bank Common Lisp

On Wed, Dec 31, 2008 at 10:22 PM, Simon Handley <shandley_42@...> wrote:
> I'm trying to track down a possible memory leak associated with SAPs, and
> I'm hoping that someone else has already seen this and I've just stupidly
> missed an obvious solution in the list archives.

I'm 90% sure that (most of?) the leak your test exhibits is actually
caused by test itself: without your code you can see that the test
conses quite a bit itself. I'm thinking that when your code is loaded
it simply conses even more, and some things end up inopportunely
tenured -- and finally you run out of space.

Looking at the generation breakdown I'm thinking that (GC :GEN 2)
after MAP-ALLOCATED-OBJECTS should be sufficient to unkink this.

(What you are seeing is the result of an unfortunate combination of
issues in MAP-ALLOCATED-OBJECTS and the generational GC.)

Additionally, I would strongly suggest passing T as the third argument
to MAP-ALLOCATED-OBJECTS.

Cheers,

 -- Nikodemus

On Sat, Jan 10, 2009 at 9:28 PM, karol skocik <karol.skocik@...> wrote:
> Hi,
>  thanks for clarification,
>
>>  (declaim (sb-ext:freeze-type foo))
>>
>
> I will follow advice 3. along with others and rewrite our most
> performance sensitive classes as structs, so I guess this declamation
> can't hurt then.

It won't really help either -- it will only change the way TYPEP test
for frozen types are compiled slightly, without any real performance
advantage. Add to that the fact that if/when proper inheritance
sealing is implemented, the FREEZE-TYPE declamation is likely to be
deprecated, I would recommend against using it.

Cheers,

 -- Nikodemus