[LLVMdev] memory leaks at compiler termination
dmitry at kernelgen.org
Sat Mar 2 10:25:02 PST 2013
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 :)
2013/3/2 Justin Holewinski <justin.holewinski at gmail.com>
> On Sat, Mar 2, 2013 at 12:56 PM, Alexander Potapenko <glider at google.com>wrote:
>> On Mar 2, 2013 3:18 AM, "reed kotler" <rkotler at mips.com> wrote:
>> > Does LLVM try and make sure that all memory is freed before compiler
>> > 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.
>> > Reed
>> > _______________________________________________
>> > LLVM Developers mailing list
>> > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> Justin Holewinski
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev