'leaks' Branch objects

Also assigning bzr because I think it is cleanest as a Branch.finalize sort of action.

Have you confirmed these are actually garbage collectable cycles, by for instance adding `gc.collect()` in you +memdump page and seeing the branches no longer present? I'd be surprised if even the Python collector let 300MB stay alive for long. If the objects are unreachable, that needs fixing in bzr. If loggerhead is accidentally stashing them somewhere however, that needs changing. Adding a finalize may help things for users of bzrlib, but could also cause confusion about whether a Branch object is dead or not.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/13/2011 04:29 PM, Martin [gz] wrote:
> Have you confirmed these are actually garbage collectable cycles, by for
> instance adding `gc.collect()` in you +memdump page and seeing the
> branches no longer present? I'd be surprised if even the Python
> collector let 300MB stay alive for long. If the objects are unreachable,
> that needs fixing in bzr. If loggerhead is accidentally stashing them
> somewhere however, that needs changing. Adding a finalize may help
> things for users of bzrlib, but could also cause confusion about whether
> a Branch object is dead or not.
>

I'm not 100% positive, but when I was testing I did SIGQUIT,
'gc.collect()' and got 20700 back. (Meaning gc found 20,000 items that
it could garbage collect.)

My guess is that the objects lived long enough to make it into the
third-tier, so don't get garbage collected often. (Which isn't very hard
if something actively creates a lot of objects for a while, and then is
done with them. Since creating all those objects triggers the
lightweight gc runs, which moves them into the next tier of gc.)

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2lttkACgkQJdeBCYSNAAMgnACeMZKlx/UgjH636OCTstLv7IBE
6IcAnRY9Smk/XQRp81nNP7BH+7nSoWiO
=XxTY
-----END PGP SIGNATURE-----