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 >>> >>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181112/852cc1c5/attachment.html>
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<mailto: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<mailto: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<mailto: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<mailto:dblaikie at gmail.com>> Sent: Mittwoch, 7. November 2018 17:34 To: Gaier, Bjoern <Bjoern.Gaier at horiba.com<mailto:Bjoern.Gaier at horiba.com>> Cc: llvm-dev <llvm-dev at lists.llvm.org<mailto: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<mailto: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<mailto: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/47913413/attachment.html>
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>