Re: [gc-improv] Permanent vs function RTL obstack fix

[Jeff Law <law@redhat.com>]

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

On 04/10/11 12:22, Laurynas Biveinis wrote:
> 
> It is certainly true that moving away from GC will make some kinds of
> bugs possible again, but I hope that not enough to be an unmanageable
> concern.
It's definitely a huge concern.  More for tree objects than RTL objects
though.



 The RTL object lifetimes seem to be clear in most of the
> instances and so far I am going with only two of them: permanent and
> function. After the initial conversion is done, I don't expect much
> trouble for any new RTL allocations introduced to be decided which
> memory area they belong to.
> 
> Adding a third area, e.g. per-TU, of course would complicate this, but
> I still believe this is manageable.
So what's the plan for the case where you need to change the lifetime of
an object?    What's the plan for building some kind of consistency
checking to ensure that we aren't referencing dangling pointers.

I ask these questions because they were a serious source of problems in
the past and any significant revamping of memory management needs to
have a reasonable story for how to deal with them, else we're taking a
rather significant step backwards.

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

iQEcBAEBAgAGBQJNo1+YAAoJEBRtltQi2kC7LeMH/2pxPMnlJAsjiwHApURV/sxX
5XyGBvawPs1W6zobBRUeOhIrfn8hSm6P2QywZvj7EpfTbiD/aKdVXz8zBOC2J1IG
69TDQwXY4YhqEW5WxTsBK6YAoFTALebZe6dbLRuN5795X+d5rSZmlyiX/GgICB7M
2iMqqkH6kv9wO2k6pfeN6k+hIHZmpVHRg3KeADTWvO5+3FKkVWFizA3LHhPf/pDM
7sG5o6CB8AI7PBNgh6A7xNs045NexIhEdkQ/R7jQNpySk3XHpfOPhjKh135hWwnw
6UoR8xqned5nr1sj6n07i+hSvYDLT6Izm68ZnFe5E09lPemVe4rZnO6Sb/+fhOA=
=gD9u
-----END PGP SIGNATURE-----