memory leaks at compiler termination

Does LLVM try and make sure that all memory is freed before compiler exit?

For example, It seems like the ARM constant pool code that I'm reading will leave a lot of un-deallocated memory.

Maybe I'm missing something here.

Reed

Does LLVM try and make sure that all memory is freed before compiler exit?

For example, It seems like the ARM constant pool code that I’m reading will leave a lot of un-deallocated memory.

Maybe I’m missing something here.
Is it that necessary to have the compiler free everything?
It usually makes sense to ensure all the allocated memory is still reachable (i.e. there are no uncontrollable leaks), but if there are pointers to that memory it should be fine to leave that memory unfreed to speed up the process shutdown.

Alexander Potapenko <glider@google.com> writes:

Is it that necessary to have the compiler free everything?

Yes, at least for those parts which can be used by the JIT.

[snip]

>
> Does LLVM try and make sure that all memory is freed before compiler
exit?
>
> For example, It seems like the ARM constant pool code that I'm reading
will leave a lot of un-deallocated memory.
>
> Maybe I'm missing something here.
Is it that necessary to have the compiler free everything?
It usually makes sense to ensure all the allocated memory is still
reachable (i.e. there are no uncontrollable leaks), but if there are
pointers to that memory it should be fine to leave that memory unfreed to
speed up the process shutdown.

It can be very important if you're using llvm/clang as a library instead of
a stand-alone process. If a compilation does not free all of its memory
and is repeatedly invoked, this can lead to increasing memory usage. I'm
not saying this is the case for the ARM constant pool (I don't know).

I've recently ran into an issue where the PassRegistry is not completely
cleaned up on exit.

True, important for us too, we are heavily JIT-ing with LLVM. In this case, LLVM should generally minimize its influence on client application, not limited to memory leaks. It should even have some extra reserve of stability to resist a buggy client applications :slight_smile:

  • D.

2013/3/2 Justin Holewinski <justin.holewinski@gmail.com>