On 11/19/14 10:11, David Malcolm wrote:
Thanks - though the patch I posted uses the contrib/valgrind.supp file,
which I added before seeing the --enable-valgrind-annotations configure
option that does a better job of this. So I'll revise it to remove that
suppression file (and add some usage notes to the internals/index.rst
document).
Sounds good.
All this work is definitely appreciated -- Jakub usually does similar
stuff later in the release process, so you're offloading some stuff from
him, which definitely helps.
Yeah - leaks are a much bigger issue for libgccjit.so than for e.g. cc1:
people embedding it into long-running processes like, say, an X server
aren't going to be happy about slow leaks.
Yea, so imagine shoving libbfd into a link server, which had a GC
collected class around bfd *. One of the key features of the link
server was that it cached information across invocations.
Sooo, we tended to never let go of the underlying BFD objects. Which
wouldn't have been too bad, except that the underlying BFD objects tend
to want to cache section contents.
So this server sat on a mount point and anytime you referenced a file,
it'd consult its little database of "how do I build XYZ". You didn't
have to reference too many files before the damn server ate all your
memory. All in the name of automagically reordering executables...
But I digress...
Jeff
