[LLVMdev] Making it possible to clear the LLVMContext

[Marcello Maggioni]

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.


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
> >> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140624/d17af719/attachment.html>