search for: jitmemorymanag

...:) > But how can I do this? The obvious way would be for me to inherit > from DefaultMemoryManager and pass an instance of my class to > ExecutionEngine::createJIT. Correct. > But DefaultMemoryManager isn't public so > I can't inherit from it. You should inherit from JITMemoryManager. > It's not at all obvious to me how I'm > supposed to intercept endFunctionBody. > > Here's how vmkit does it: class MvmMemoryManager : public JITMemoryManager { /// realMemoryManager - The real allocator JITMemoryManager* realMemoryManager; public: MvmMem...

Here's my problem, which I raised on IRC: JIT::getPointerToFunction gets the address of the start of a function. But how do I find out where the end of the function is? I need this to register the function for profiling. varth said: aph, you need to intercept the "endFunctionBody" call on the memory manager, it will tell you the start pointer and the end pointer But how can I do

Hi Paul, I'm surprised to hear that you aren't seeing any adverse effects. As I understand it, the memory for the function pointer returned by getPointerToFunction is owned by the JITMemoryManager which was used in creating the ExecutionEngine. In the case of the legacy JIT engine, the JITMemoryManager is owned by the JITEmitter which in turn is owned by the JIT ExecutionEngine. In the case of the new MCJIT engine, the JITMemoryManager is owned by the MCJITMemoryManager which in turn is...

I'll try to find out, or get someone to explain, why Mesa selects MCJIT with LLVM 3.1 only and JIT for other LLVM versions. I'm not keen to code a fourth attempt (1: copy JIT code, 2: delegating manger, 3: derive from DefaultJITMemoryManager, 4: copy MCJIT code) but I'll try copying code with MCJIT. Is that the usual route for people who want to delete all LLVM engines, etc. while keeping the generated code? In any case, my points on the difficulty of creating a JITMemoryManager apply equally to JIT or MCJIT. Maybe few people c...

Given: typedef MyClass* (*jit_fn_ptr_type)(); MyClass* set_fn( llvm::Function *fn ) { // create an ExecutionEngine 'exec' ... jit_fn_ptr_type fn_ptr = (jit_fn_ptr_type)exec->getPointerToFunction( fn ); return fn_ptr(); } After I call getPointerToFunction() to obtain the pointer to the JIT'd function and fun the function (that will produce an instance of MyClass on the

...en delete the engine. This might be doable with MCJIT, but seemingly not with JIT which Mesa wants to use. 2) A new memory manager with less overhead and which also doesn't delete the code when killed by the engine. I've got solution 2 working, but LLVM could make it easier. Deriving from JITMemoryManager seems complicated - there are a lot of methods to implement. Deriving from DefaultJITMemoryManager is not possible because it's in an anonymous namespace. So I made a manager that delegates everything to a shared default memory manager. This eliminates overhead by packing everything into o...

...is might be > doable with MCJIT, but seemingly not with JIT which Mesa wants to use. > 2) A new memory manager with less overhead and which also doesn't > delete the code when killed by the engine. > I've got solution 2 working, but LLVM could make it easier. Deriving > from JITMemoryManager seems complicated - there are a lot of methods > to implement. Deriving from DefaultJITMemoryManager is not possible > because it's in an anonymous namespace. So I made a manager that > delegates everything to a shared default memory manager. This > eliminates overhead by packi...

On 07/06/2011 08:28, Jim Grosbach wrote: > Hi Yuri, You're correct that the current JITMemoryManager interface > isn't a very good fit for the MCJIT. For the time being though, the > intent is to work with it as much as possible so that the MCJIT can be > a drop-in replacement for the old JIT. If we change the > JITMemoryManager API right off the bat, we'll make it that m...

...al Studio shut up (and possibly to make LLVM more 64bit friendly). I > chose to typedef a size_type on the LLVM containers that try to mimic > the std:: containers, while in the other case I just made a simple cast. > > Finally the leaks.patch file contains a destructor for the > JITMemoryManager that frees system memory and a minor modification to > how one particular singleton object gets instantiated in CommandLine.cpp > to stop the VS leak detector complaining. > > m. > > ______________________________________________________________________ > Index: lib/Execu...

...odification to make Visual Studio shut up (and possibly to make LLVM more 64bit friendly). I chose to typedef a size_type on the LLVM containers that try to mimic the std:: containers, while in the other case I just made a simple cast. Finally the leaks.patch file contains a destructor for the JITMemoryManager that frees system memory and a minor modification to how one particular singleton object gets instantiated in CommandLine.cpp to stop the VS leak detector complaining. m. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: leaks.patch URL: &lt...

...ous way would be for me to inherit >> from DefaultMemoryManager and pass an instance of my class to >> ExecutionEngine::createJIT. > > Correct. > >> But DefaultMemoryManager isn't public so >> I can't inherit from it. > > You should inherit from JITMemoryManager. >> It's not at all obvious to me how I'm >> supposed to intercept endFunctionBody. > > Here's how vmkit does it: > > class MvmMemoryManager : public JITMemoryManager { > > /// realMemoryManager - The real allocator > JITMemoryManager* realMemo...

...o > be initialized to be false yet. Can you add a mechanism to define the > behavior when the JIT is created / initialized? That makes four optional arguments to ExecutionEngine::create. Do you mind if I go ahead and add an EngineBuilder? > Also, I am not crazy about this being moved to JITMemoryManager.h. > This seems like implementation detail that should be kept hidden. > > +  // If the PoisonMemory parameter is true, freed memory should be > overwritten > +  // with garbage.  This parameter is useful for testing and debugging. > +#ifdef NDEBUG > +#define POISON true >...

...> So is this a design flaw that should be fixed? Or am I missing something? > > I think I can lower the allocator from MCJIT into inside of RuntimeDyld. So at least ELF will be able to use the bulk allocator. But I though I ask here first. Hi Yuri, You're correct that the current JITMemoryManager interface isn't a very good fit for the MCJIT. For the time being though, the intent is to work with it as much as possible so that the MCJIT can be a drop-in replacement for the old JIT. If we change the JITMemoryManager API right off the bat, we'll make it that much harder for clients t...

I noticed that JITMemoryManager allocates its slabs as rwx. Isn't it a security problem to have memory mapped as both writable and executable? I think JITs often avoid this by mapping their memory as rw, then switching it to rx once the data has been written. I was facing a similar problem in a JIT of my own and was curi...

...ne->InstallLazyFunctionCreator(&MyLazyFunctionCreator); which works fine with the JIT. However, MCJIT insists on resolving unknown symbols by searching them outdoors and seems oblivious of the existence of MyLazyFunctionCreator. Is this a bug? Is there a workaround, other than subclassing JITMemoryManager and implementing my own getPointerToNamedFunction? (which would make the existence of ExecutionEngine::InstallLazyFunctionCreator pointless.)

...s common to the JIT and MCJIT though (and even the interpreter for Linux/x86). > > Second, unless I'm reading it wrong, this relies on static constructors. That causes headaches and is against the LLVM coding standards. My bad, I just ripped off the existing implementation. I guess the JITMemoryManager part is destined to go away along with the JIT. > > Third, I don't think sys::DynamicLibrary::AddSymbol() is the right way to go here. I know I have recently suggested using that function, but I was wrong. That function exposes symbols to the entire host program as if they were presen...

I am implementing ELFObject class for MCJIT to be able to run ELFs on ELF-platforms. One thing bothers me: I see that the RTDyldMemoryManager-based allocator is always passed to MCJIT and to RuntimeDyld classes from outside. This enforces the approach that memory will be allocated function by function with startFunctionBody/endFunctionBody. This maybe was good for the old JIT, but not for

The patch looks good to me. But we cannot allow AllocateGVsWithCode to be initialized to be false yet. Can you add a mechanism to define the behavior when the JIT is created / initialized? Also, I am not crazy about this being moved to JITMemoryManager.h. This seems like implementation detail that should be kept hidden. + // If the PoisonMemory parameter is true, freed memory should be overwritten + // with garbage. This parameter is useful for testing and debugging. +#ifdef NDEBUG +#define POISON true +#else +#define POISON false +#end...

Well, is the attached version better? I've extended the RTDyldMemoryManager hooks instead to pick up the ARM math functions statically, and left JITMemoryManager alone except for changing the conditional so that it will build with non-glibc libraries. I've also split the original patch up into two parts, to separate the math function fixes from setLastModificationAndAccessTime. The second patch modifies the setLastModificationAndAccessTime functio...

...odules and their content are not available at a time when some of jitted pieces are already in use. Is it feasible to destruct ExecutionEngine but keep jitted code alive? Are jitted binary codes position independent? (or is there a way to relocate) If the solution requires custom implementation of JITMemoryManager: is there a way to get exact (or sufficient) memory size for binary code before the actual code generation? Regards, Mikhail