[llvm-dev] JIT-Client for Shared Memory

Tue Nov 20 14:59:36 PST 2018

Hi Bjoern,

But this function would still be called for each module I add to a
> JIT-Process?

That is correct.

> Seems like I have to use the LLVM-Link code first to link all the modules
> to one big.

If you want to be able to do a single shared memory allocation, then yes:
the only option at the moment is to link all modules together first.

Cheers,
Lang.

On Tue, Nov 20, 2018 at 5:52 AM Gaier, Bjoern <Bjoern.Gaier at horiba.com>
wrote:

> Hello Lang,
>
>
>
> This function is exactly what I was looking for! Thank you a lot!
>
> But this function would still be called for each module I add to a
> JIT-Process? Seems like I have to use the LLVM-Link code first to link all
> the modules to one big.
>
>
>
> That still helped me a lot! Thank you so much!
>
>
>
> Kind greetings
>
> Björn
>
>
>
> *From:* Lang Hames <lhames at gmail.com>
> *Sent:* Montag, 12. November 2018 16:42
> *To:* David Blaikie <dblaikie at gmail.com>
> *Cc:* Gaier, Bjoern <Bjoern.Gaier at horiba.com>; LLVM Developers Mailing
> List <llvm-dev at lists.llvm.org>
> *Subject:* Re: [llvm-dev] JIT-Client for Shared Memory
>
>
>
> Hi Bjoern,
>
>
>
> For single object files you can override the needsToReserveAllocationSpace
> method that is inherited from  llvm::RuntimeDyld::MemoryManager (make it
> return true) and then implement the reserveAllocationSpace method to
> allocate memory for all sections up front.
>
>
>
> There is no easy way to do this for multiple object files. I think you
> would have to mimic the memory size calculations performed by RuntimeDyld,
> then pre-allocate the memory yourself.
>
>
>
> BUT... There is one problem. The shared memory can't be dynamical
> adjusted. So if I add another module to the current module, then I would go
> through this process again! Not the "finalizeMemory" process though, but I
> would allocate another shared memory. This is not what I want! Currently I
> use the linker first, to work around this problem, but this will not help
> me if I add object files or libraries to the JIT process - or does it?
>
>
>
> Unless all of your code is pre-compiled (i.e. you can calculate the
> required allocations up-front) I do not think this can be avoided. I think
> the best you can do is conservatively over-allocate shared memory in the
> hope that you do not end up needing to make a second allocation.
>
>
>
> Cheers,
>
> Lang.
>
>
>
> On Wed, Nov 7, 2018 at 11:12 PM David Blaikie <dblaikie at gmail.com> wrote:
>
> And then I used reply instead of reply-all... I'm on a roll. Added
> llvm-dev back again... So maybe this is right now. Maybe - sorry for the
> confusion
>
> On Wed, Nov 7, 2018, 11:11 PM David Blaikie <dblaikie at gmail.com wrote:
>
> Well I meant to add him but failed. Cc'd him here now :)
>
> On Wed, Nov 7, 2018, 10:41 PM Gaier, Bjoern <Bjoern.Gaier at horiba.com
> wrote:
>
> Is… Lang now added? I’m not sure about this system…
>
> My problem is that I can not change the size of the shared memory I’m
> targeting – so I can only allocate it once, but how do I know how much
> memory I’m going to need, when each sections requests the memory after each
> other?
> To work around this I first allocate the memory locally and count the
> bytes it needed. After notifyObjectLoaded I can request the shared memory
> and do the mapping. But this only covers one module. If I have two modules
> for example, then I will end up having two shared memories, because the
> second module will go through the same steps as the first one. But I want
> to have one coherent memory.
>
>
>
> Also the applying of the mapping causes a bug with the new LLVM7 – I
> already filled out a bug report for this. But I have no idea how things
> will progress from that point… Still I have no idea about the system…
>
>
>
> *From:* David Blaikie <dblaikie at gmail.com>
> *Sent:* Mittwoch, 7. November 2018 17:34
> *To:* Gaier, Bjoern <Bjoern.Gaier at horiba.com>
> *Cc:* llvm-dev <llvm-dev at lists.llvm.org>
> *Subject:* Re: [llvm-dev] JIT-Client for Shared Memory
>
>
>
> Adding Lang here in case he's got some insight.
>
> I take it the system you're targeting doesn't have the memory limitations
> that some systems have, where once memory is set executable, it can never
> be written to? & so you'd like to write some code into a page, execute it,
> write some more code into the same page and have that execute too?
>
> (I don't know teh JIT architecture well enough to know if that's
> supported, or if I'm accurately understanding your situation, etc)
>
> On Thu, Nov 1, 2018 at 11:49 PM Gaier, Bjoern via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> Hello everyone,
>
>
>
> I want to use the LLVM to write a JIT client, that works with shared
> memory. Currently I proceed as following:
>
>
>
> I wrote an own class that inherits "*RTDyldMemoryManager*". The functions
> "*allocateCodeSection*" and "*allocateDataSection*" are allocating local
> non-shared memory. I store there addresses in a std::vector.
>
> When the function "*notifyObjectLoaded*" is invoked, I allocate the
> shared memory - I'm getting the size from the local non-shared memory - and
> apply the address mapping.
>
> When the function "*finalizeMemory*" is invoked I copy the code from the
> local non-shared memory to the shared memory but only one time.
>
>
>
> So far so good, this works actually good! Yippie x3
>
>
>
> BUT... There is one problem. The shared memory can't be dynamical
> adjusted. So if I add another module to the current module, then I would go
> through this process again! Not the "*finalizeMemory*" process though,
> but I would allocate another shared memory. This is not what I want!
> Currently I use the linker first, to work around this problem, but this
> will not help me if I add object files or libraries to the JIT process - or
> does it?
>
>
>
> So is there any way to work around this?
>
>
>
> Kind greetings
>
> Björn
>
> Als GmbH eingetragen im Handelsregister Bad Homburg v.d.H. HRB 9816,
> USt.ID-Nr. DE 114 165 789 Geschäftsführer: Dr. Hiroshi Nakamura, Dr. Robert
> Plank, Markus Bode, Heiko Lampert, Takashi Nagano, Takeshi Fukushima.
> Junichi Tajika
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> Als GmbH eingetragen im Handelsregister Bad Homburg v.d.H. HRB 9816,
> USt.ID-Nr. DE 114 165 789 Geschäftsführer: Dr. Hiroshi Nakamura, Dr. Robert
> Plank, Markus Bode, Heiko Lampert, Takashi Nagano, Takeshi Fukushima.
> Junichi Tajika
>
> Als GmbH eingetragen im Handelsregister Bad Homburg v.d.H. HRB 9816,
> USt.ID-Nr. DE 114 165 789 Geschäftsführer: Dr. Hiroshi Nakamura, Dr. Robert
> Plank, Markus Bode, Heiko Lampert, Takashi Nagano, Takeshi Fukushima.
> Junichi Tajika
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181120/05f0298c/attachment.html>