search for: jit_memory_manager

...bal JIT memory manager. The per request JIT memory manager gets memory from the global manager, but both ended up implementing (almost) the whole memory manager api, because I couldn't find another way to do it. Also see the code here: https://github.com/rubinius/rubinius/blob/master/vm/llvm/jit_memory_manager.hpp https://github.com/rubinius/rubinius/blob/master/vm/llvm/jit_memory_manager.cpp If there are better ways to clean up the code, that would be great, but having to things like that is what made me state feeling dirty on how it was implemented. -- Dirkjan On Mar 19, 2013, at 01:56 , "Ka...

...obal JIT memory manager. The per request JIT memory manager gets memory from the global manager, but both ended up implementing (almost) the whole memory manager api, because I couldn't find another way to do it. Also see the code here: https://github.com/rubinius/rubinius/blob/master/vm/llvm/jit_memory_manager.hpp https://github.com/rubinius/rubinius/blob/master/vm/llvm/jit_memory_manager.cpp If there are better ways to clean up the code, that would be great, but having to things like that is what made me state feeling dirty on how it was implemented. -- Dirkjan On Mar 19, 2013, at 01:56 , "Kayl...

I'm not sure I see why the delegating memory manager feels wrong to both of you. That's exactly the kind of usage model I would envision for clients that needed to handle multiple ExecutionEngines that had reason to share a memory manager. I'm saying this as an invitation to discussion, not to be argumentative. We certainly could change things if it would make the design better.

Thanks for the reply, nice to have some validation. I thought of another approach which might be preferable: generate relocatable code, use a JITEventListener to grab each function and copy it to my own memory, let all the LLVM stuff die normally then use my copy of the code. However when I call setRelocationModel(Reloc::PIC_) on the engine builder I get code that seg faults. The assembly looks