plugged a memleak

plugged a memleak

[Andy Wingo]

Hi all,

I just fixed a long-standing memory leak in Guile 2.0.  (I say that like
I'm proud or something, but of course I was the one the introduced it in
the first place!)

See c05805a4ea764dec5a0559edefcdfb9761191d07 in stable-2.0 for the
gnarly details.  The summary is that applicable smobs were being leaked,
because they were referenced in the values of weak-key tables.

This fixes Guile's compilation, where compiling eval.go would take half
a gig of memory.  It also fixes the web server, where
call-with-output-bytevector would leak a reference to the port and
bytevector.  Probably it fixes a number of other leaks.

Anyway, applied on both branches.

Happy hacking,

Andy
-- 
http://wingolog.org/

Re: plugged a memleak

[Ludovic Courtès]

Hi!

Andy Wingo <wingo@pobox.com> skribis:

> I just fixed a long-standing memory leak in Guile 2.0.  (I say that like
> I'm proud or something, but of course I was the one the introduced it in
> the first place!)

Excellent!

> See c05805a4ea764dec5a0559edefcdfb9761191d07 in stable-2.0 for the
> gnarly details.  The summary is that applicable smobs were being leaked,
> because they were referenced in the values of weak-key tables.

I was wondering whether removing ‘smob-call’ would break binary
compatibility, but presumably that instruction could not possibly end up
in user bytecode on disk, right?

Thanks,
Ludo’.

Re: plugged a memleak

[Andy Wingo]

On Wed 21 Mar 2012 22:02, ludo@gnu.org (Ludovic Courtès) writes:

>> See c05805a4ea764dec5a0559edefcdfb9761191d07 in stable-2.0 for the
>> gnarly details.  The summary is that applicable smobs were being leaked,
>> because they were referenced in the values of weak-key tables.
>
> I was wondering whether removing ‘smob-call’ would break binary
> compatibility, but presumably that instruction could not possibly end up
> in user bytecode on disk, right?

Presumably not.  It is documented, though.  We can remove it, but its
continued presence doesn't cost us anything.  I'm OK with either option
:)

Cheers,

Andy
-- 
http://wingolog.org/

Re: plugged a memleak

[Ludovic Courtès]

Hi,

Andy Wingo <wingo@pobox.com> skribis:

> On Wed 21 Mar 2012 22:02, ludo@gnu.org (Ludovic Courtès) writes:
>
>>> See c05805a4ea764dec5a0559edefcdfb9761191d07 in stable-2.0 for the
>>> gnarly details.  The summary is that applicable smobs were being leaked,
>>> because they were referenced in the values of weak-key tables.
>>
>> I was wondering whether removing ‘smob-call’ would break binary
>> compatibility, but presumably that instruction could not possibly end up
>> in user bytecode on disk, right?
>
> Presumably not.  It is documented, though.  We can remove it, but its
> continued presence doesn't cost us anything.  I'm OK with either option

Right, we can leave it.

Thanks!

Ludo’.