similar to: MCJit and remove module memory leak?

Hi Kevin, Koffie, We will start migrating to ORC for next release, but for now, this release > invoke delete after remove right? MCJIT's removeModule method does not delete the module. You'll need to do that manually. OrcMCJITReplacement is a bug-for-bug compatible implementation of MCJIT using ORC components, so it does not free the memory either. Does this mean MCJIT is

Hi Koffie, I'd highly recommend switching to ORC from MCJIT. It is much more flexible when it comes to memory-management. 1. I took the approach of 1 execution engine with multiple modules (I'm not > removing modules once they have been added). During profiling, I noticed > that the memory usage is high with a lot of code. How can I reduce the > memory usage? Is one execution

Firstly, apologies if this is not the right place to be asking this question--feel free to point me in the correct direction. I could be doing something wrong here but stackoverflow didn't feel like the correct place for this since there's so little there about LLVM ORC. Basically, I have a reproduction case (below) where if I throw an exception before I call JITSymbol::getAddress()

+Lang for JIT things. On Sun, Jul 24, 2016 at 8:50 AM koffie drinker via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi all, > > I'm building a runtime that can jit and execute code. I've followed the > kaleidoscope tutorial and had a couple of questions. Basically I have a > pre-compiler that compiles the code to cache objects. These cached objects > are

Hi David, This looks like bad eh-frame data due to a failure to fix up the frame descriptor entries: <debug: adding frame> EHFrameAddr: 0x7feae5827000, EHFrameLoadAddr: 0x00000000e5827000, EHFrameSize: 60 ==64588==ERROR: AddressSanitizer: SEGV on unknown address 0x7feae5827020 (pc 0x7feae886d970 bp 0x000000000001 sp 0x7ffca10e75f8 T0) Eyeballing the code in RuntimeDyldELF (vs

Hi David, Thanks very much for that. I'll continue to dig in as time permits, and I'll update the bug report with my progress once it's filed. Cheers, Lang. On Mon, Apr 17, 2017 at 6:42 PM, David Lurton <dlurton at gmail.com> wrote: > Thanks Lang. I think I'll go the bug creation route. I have an email out > to llvm-admin requesting an account on bugs.llvm.org.

Hi Lang, On Tue, 13 Aug 2019 at 22:15, Lang Hames <lhames at gmail.com> wrote: > >> 1) Can 0 ever be a valid VModuleKey? How can one reliably detect an invalid VModuleKey? > > > I believe 0 was a valid VModuleKey in ORCv1. The assertion is checking the the VModuleKey is present in the LogicalDylibs map. That means that you have to have used that key in an addModule call,

Hi all, I'm building a runtime that can jit and execute code. I've followed the kaleidoscope tutorial and had a couple of questions. Basically I have a pre-compiler that compiles the code to cache objects. These cached objects are then persisted and used to reduce Jit compile time. 1. I took the approach of 1 execution engine with multiple modules (I'm not removing modules once

Hi David, Sorry to hear. Has anyone followed up with you yet? I've continued to dig in to this in my spare time and I've found the issue. It's a use-after-free, rather than any sort of memory smashing. ORC is currently failing to deregister the EH-frame section when the JIT is torn down (but *is* deallocating the memory for it). Normally that's not disastrous (though it does

Hi, I am getting following assertion failure when attempting to remove a module. /llvm/ExecutionEngine/Orc/CompileOnDemandLayer.h:311: llvm::Error llvm::orc::LegacyCompileOnDemandLayer<BaseLayerT, CompileCallbackMgrT, IndirectStubsMgrT>::removeModule(llvm::orc::VModuleKey) [with BaseLayerT =

Hi, I think ExecutionEngine as a common interface for both Interpreter and MCJIT is almost useless in the current form. There are separated methods in ExecutionEngine for similar or the same features provided by Interpreter and MCJIT, i.e. to get a pointer to function you should call getPointerToFunction() for Interpreter or getFunctionAddress() for MCJIT. Personally, I'm using MCJIT and

Heyho, I can only provide you with a screenshot for the first problem I noticed: [https://media.discordapp.net/attachments/534012750045642783/575369402195640321/unknown.png] This code will crash when calling "eeBuilder.create". But I also looked at what happens if I do reuse the llvm::ExecutionEngine. After the call to "finalizeObject" I use "removeModule" for the

With the support of Multi-modules, it makes sense to have a creator / constructor for ExecutionEngine that does not require a module. The use-case is a program using one EE created at initialization that holds many modules created later, as needed. Workaround for current API could be 1) using a pointer to EE init with NULL, delaying the actual EE construction to the time the first module is

Dear LLVM-Mailing-List, I'm using the llvm::EngineBuilder to create an instance of the llvm::ExecutionEngine, I then JIT my code, take the addresses I need and delete the llvm::ExecutionEngine. But now I started to wonder, if I could reuse that instance for a new module again? I first tried calling llvm::EngineBuilder without setting a Module, I planned to add it later - but when I do this

Agreed, the existing ownership seems sub-optimal. I wouldn't say broken, but subtle at least - looks like you get the choice to either manage the ownership of the Module object yourself, or let the context handle it (eg: currently it'd be valid to just do "{ LLVMContext C; new Module(C); new Module(C); }" - Modules end up owned by the context and cleaned up there). Might be hard

Hi, You cannot call removeModule on a JIT with no modules: jitstate will be 0 and therefore we have a null-pointer exception. The function returns a boolean for success/failure, however, so you would expect to be able to call it and get false back. Should we be checking for jitstate != 0 before accessing the variable? - if (jitstate->getModule() == M) { + if (jitstate &&

I agree that this would be useful. One minor stumbling block is that the EngineBuilder uses the supplied Module to determine the target triple when creating the TargetMachine. Obviously that could be handled with different EngineBuilder usage (the API may even already be there for that). It's just something to consider. -Andy From: Yaron Keren [mailto:yaron.keren at gmail.com] Sent:

On Aug 18, 2010, at 10:24 AM, Reid Kleckner wrote: > You can free the machine code yourself by saying > EE->freeMachineCodeForFunction(F) . If you destroy the EE, it will > also free the machine code. Thanks, but unfortunately, this is exactly the opposite of what I want to do. I need to retain the machine code indefinitely, but I want to free all possible other resources that are

Hi all, I am using LLVM for JIT use-case and compile functions on the fly. I want to "free" the modules after some time and reclaim any memory associated with it. I am using the SimpleORC API <https://llvm.org/docs/tutorial/BuildingAJIT1.html> now. Is there an API to "free" all the memory associated with the module? I use one "compiler" instance (think similar

Hi Again, I'm a little confused regarding what is the exact Orc's functions I should use in order to save the functions code in a code cache so it could be later replaced with different versions of it and I appreciate your help. Just a reminder I want to dynamically recompile the program based on profile collected at the run-time. I would like to start executing the program from the