[llvm] r307058 - [Orc] Remove the memory manager argument to addModule, and de-templatize the

[Lang Hames via llvm-commits]

That's correct, but I believe it also matches the existing behavior: Using
a separate memory manager for each module is required so that the modules
can be removed again (RuntimeDyld::MemoryManager has no free/release
method, it just frees everything on destruction).

Part of the reason for this change was to decouple the memory management
scheme from the rest of the ORC APIs (since memory management is really an
implementation detail for the linker). This will allow us to design new
linking layers that can share an allocator and still free memory when
modules are removed.

Cheers,
Lang.



On Thu, Jul 6, 2017 at 7:08 PM, Andres Freund <andres at anarazel.de> wrote:

> Hi,
>
> On 2017-07-04 04:42:30 -0000, Lang Hames via llvm-commits wrote:>
> >      auto LO =
> > -      createLinkedObject(std::move(Obj), std::move(MemMgr),
> std::move(Resolver),
> > -                         std::move(Finalizer), ProcessAllSections);
> > +      createLinkedObject(std::move(Obj), GetMemMgr(),
> > +                         std::move(Resolver), std::move(Finalizer),
> > +                         ProcessAllSections);
> > Modified: llvm/trunk/lib/ExecutionEngine/Orc/OrcCBindingsStack.h
> > URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/
> ExecutionEngine/Orc/OrcCBindingsStack.h?rev=307058&r1=307057&r2=307058&
> view=diff
> > ============================================================
> ==================
> > --- llvm/trunk/lib/ExecutionEngine/Orc/OrcCBindingsStack.h (original)
> > +++ llvm/trunk/lib/ExecutionEngine/Orc/OrcCBindingsStack.h Mon Jul  3
> 21:42:30 2017
> > @@ -105,6 +105,10 @@ public:
> >                      IndirectStubsManagerBuilder IndirectStubsMgrBuilder)
> >        : DL(TM.createDataLayout()), IndirectStubsMgr(
> IndirectStubsMgrBuilder()),
> >          CCMgr(std::move(CCMgr)),
> > +        ObjectLayer(
> > +          []() {
> > +            return std::make_shared<SectionMemoryManager>();
> > +          }),
>
> Doesn't this mean we'll, at least if GetMemMgr() returns a new mmgr as
> the case in the OrcC stack, create a new mmgr for every object? That
> seems suboptimal?
>
> - Andres
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170707/42eca722/attachment.html>