[LLVMdev] Making it possible to clear the LLVMContext

Tue Jun 24 11:30:13 PDT 2014

Sent from my iPhone

> On Jun 24, 2014, at 13:53, Marcello Maggioni <hayarms at gmail.com> wrote:
> 
> An example is that a lot of data just accumulates between different compilations, like Constants for example or MDNodes.
> 
> In the long run the memory hogged starts to become a concern.
> 
> 

It would be awesome if we could just move these to the module, but I understand that it would harm some users.

Some time ago there was a suggestion of adding some gc functionality to clear constants and metadata not used by any module.

> 2014-06-24 18:51 GMT+01:00 David Blaikie <dblaikie at gmail.com>:
>> On Tue, Jun 24, 2014 at 10:44 AM, Marcello Maggioni <hayarms at gmail.com> wrote:
>> > Hello,
>> >
>> > the need here is to have a single LLVMContext used for multiple
>> > compilations.
>> 
>> What I'm trying to understand is why is that a need - is that not
>> equivalent to just building a new LLVMContext for each compilation? Is
>> there a performance concern (with data to back it up?) about doing
>> that?
>> 
>> What is it that goes wrong if you just start the next compilation
>> without clearing the context in any way? (what's the persistent state
>> that interferes with the next run?)
>> 
>> - David
>> 
>> >
>> > You make a good point about that by the way. If there are outstanding users
>> > cleaning the context under their seats might still pose a risk to them, and
>> > in that case deleting + newing a new LLVMContextImpl might actually not be
>> > very different.
>> >
>> > Marcello
>> >
>> > 2014-06-24 17:14 GMT+01:00 David Blaikie <dblaikie at gmail.com>:
>> >
>> >> What're the situation in which you need to clear it? If there are
>> >> outstanding users of it (given that you mention clients possibly
>> >> holding references to the pimpl, it sounds like you might have
>> >> outstanding users) then wouldn't they be at risk of breaking if you
>> >> mutate the LLVMContext underneath them?
>> >>
>> >> & if you don't have outstanding users, is there any particular benefit
>> >> to resetting the LLVMContext compared to just making a new one?
>> >>
>> >> On Tue, Jun 24, 2014 at 7:18 AM, Marcello Maggioni <hayarms at gmail.com>
>> >> wrote:
>> >> > Hello,
>> >> >
>> >> > I'm trying to develop a way to reliably clean the LLVMContext in order
>> >> > to
>> >> > make it possible to use it multiple times.
>> >> >
>> >> > LLVMContext itself is an almost empty object delegating almost all its
>> >> > content to LLVMContextImpl.
>> >> > This makes it very clean ideally, because clearing the LLVMContext would
>> >> > be
>> >> > as easy as deleting the LLVMContextImpl and creating a new one.
>> >> >
>> >> > The problem is that for some reason which I'm not aware of
>> >> > LLVMContextImpl
>> >> > is actually exposed as a public pointer in the LLVMContext
>> >> > interface,making
>> >> > it publicly available to objects that use it directly (this seems to
>> >> > happen
>> >> > quite a lot in the codebase).
>> >> >
>> >> > In LLVMContext the LLVMContextImpl is contained in a pImpl pointer that
>> >> > is
>> >> > const (the pointer itself can't be changed) and I guess this is some
>> >> > kind of
>> >> > protection against object replacing the LLVMContextImpl directly, which
>> >> > stops us from just deleting it + getting a new one.
>> >> > In addition to that, being pImpl public, there is no guarantee that
>> >> > objects
>> >> > don't rely on pImpl remaining always the same pointer.
>> >> >
>> >> > This makes it more difficult to clear LLVMContext.
>> >> >
>> >> > An approach I thought of could be adding a clear() method to LLVMContext
>> >> > that:
>> >> >  - Calls directly the destructor of LLVMContextImpl on the pImpl object
>> >> >  - Uses a placement new to reinitialize the object.
>> >> >  - Recreates the fixed metadata kinds like the LLVMContext constructor
>> >> > does
>> >> >
>> >> > I'm attaching a patch that show this approach in this mail.
>> >> >
>> >> > I would like to know a general idea about what people think about this
>> >> > and
>> >> > see what people think would be the best approach would be.
>> >> >
>> >> > Thanks,
>> >> > Marcello
>> >> >
>> >> > _______________________________________________
>> >> > 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
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140624/680e2981/attachment.html>