similar to: [LLVMdev] Memory clean for applications using LLVM for JIT compilation

On Mon, Jan 14, 2013 at 4:56 AM, Dirkjan Bussink <d.bussink at gmail.com>wrote: > Hello all, > > I've already bothered people on IRC with this question and it was > recommended to ask it here. > > First of all, some context. In Rubinius (http://rubini.us/, > http://github.com/rubinius/rubinius) we use LLVM for our JIT. We create > LLVM IR using the C++ API and

Hi Andy, One of the issues that I found not intuitive, is that when an ExecutionEngine is deallocated, the memory manager's destructor is also called. This resulted in having to write two objects in my case, one as a per JIT request memory manager and one global JIT memory manager. The per request JIT memory manager gets memory from the global manager, but both ended up implementing

Hi Dirkjan, Are you using JIT or MCJIT? Cheers. ________________________________________ From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] on behalf of Dirkjan Bussink [d.bussink at gmail.com] Sent: Saturday, March 23, 2013 8:18 AM To: Kaylor, Andrew Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Memory clean for applications using LLVM for JIT compilation Hi Andy, One

Hello, In Rubinius we're seeing an occasional crash inside LLVM that always happens inside getenv(), which is used for example when creating a MCContext (inside lib/MC/MCContext.cpp, it checks getenv("AS_SECURE_LOG_FILE")). The problem is that getenv() and friends aren't thread safe and Rubinius provides a multithreaded system. We can relatively easily get locking setup around

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

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.

Right. glibc's amusing stance is that you setenv/putenv are not thread safe, but getenv is. I assume Ruby exposes setenv and therefore simply not calling setenv isn't an option. Would it solve your problems if all getenv() calls happened at cl::ParseCommandLineOptions() time? On Thu, May 23, 2013 at 9:49 AM, Dirkjan Bussink <d.bussink at gmail.com>wrote: > Hello, > >

On 14 Jan 2013, at 15:48, Reid Kleckner <rnk at google.com> wrote: > > Or maybe would it be possible to have a custom allocator for memory space for the native code that we could provide? With this last option we would be responsible for the clean up ourselves and just provide memory space to LLVM where it can store the results. > > Yes, you should be able to inherit from

Hi all, I'd like to ask about something I've been thinking about and haven't found a way to make this possible with LLVM, so I'm wondering whether I'm not looking properly or that indeed that can't be done currently. What I'm trying to do is to be able to modify generated assembly code after it has been created through LLVM. At this point the original LLVM IR

> On 14 Jan 2013, at 15:48, Reid Kleckner <rnk at google.com> wrote: > > > > Or maybe would it be possible to have a custom allocator for memory space for the native code that we could provide? With this last option we would be responsible for the clean up ourselves and just provide memory space to LLVM where it can store the results. > > > > Yes, you should be

Before anything else, let me state this: Of course it''s going to be PAINFULLY slow on MRI. That''s not the point :) I thought I''d try out writing out a Ruby version of the parser for the purposes of Rubinius. For those of you who aren''t aware, Ragel supports a goto-driven FSM on Rubinius by injecting assembly directly, and Rubinus head honcho guy Evan Phoenix

Hello all, When using the JIT on ARM, I get the following error message. The code works fine on both X86 32 and 64 bit architectures. rbx: /home/dirkjan/llvm-3.3.src/include/llvm/CodeGen/MachineOperand.h:260: unsigned int llvm::MachineOperand::getReg() const: Assertion `isReg() && "This is not a register operand!"' failed. Program received signal SIGABRT, Aborted.

It seems wrong to delegate a dozen or more methods when I only want to change the behavior in a couple small ways. It would have been easier to derive a class, but the base class is inaccessible (in an anonymous namespace). And I was afraid to roll my own memory manager because I didn't understand what all those methods do. So MCJIT is future - will JITMemoryManager remain relevant? If so I

On Mar 7, 2013, at 20:48 , Frank Henigman <fjhenigman at google.com> wrote: > I derived a class from JITMemoryManager which delegates everything to > an instance made with CreateDefaultMemManager(). ExecutionEngine > destroys the wrapper, but I keep the inner instance which did the > actual work. Works, but seems a bit ugly. Did you find any other > solutions? I ended up

Hi, I'm testing how to free memory of a JIT'd function. I thought ExecutionEngine::freeMachineCodeForFunction() and Function::eraseFromParent() would work and did a test with the following sample code. But I found that the memory usage of the process is constantly growing as the while loop goes. Could someone shed light on this please? Here is the code. int main(int argc, char **argv) {

Nicholas, > What if I want to have global llvm::Type's, that can be used by many > LLVMContext's. For example, I'd like to have one LLVMContext per > function, and be able to create constants that belong to the context > but using a global, shared amongst LLVMContext's, llvm::Type. > > I know that's not doable right now, but aren't we losing this >

> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Dirkjan Bussink > Subject: [LLVMdev] Modifying machine code after it's generated with LLVM > I'd need to be able to pass a memory address where the actual native > code is generated to this fallback function, but I haven't found any > ways of doing this. Perhaps I don't

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've been reading the headers and http://llvm.org/releases/2.1/docs/ProgrammersManual.html and I'm still confused about a pretty fundamental point... who is expected to clean up various objects when we're finished with them, and when? Let's say I've created a module, retrieved a bunch of types, created a function, a basic block,

Owen Anderson wrote: > That wasn't going to be possible with the methods-on-LLVMContext > either. The Type uniquing tables will be moving onto the context for > similar reasons to the Constant ones, though we will make an effort to > preserve the existing APIs. OK. > > I'm not sure I understand your goal with having one context per > function. The goal is to

Hi, I put the sample code and a brief analysis using Valgrind to GitHub in order to make my problem clear. https://github.com/naosuke/how-to-free-memory-of-JIT-function The Valgrind heap profiler indicates memory leaking but I don't get what is wrong with the way to free memory. If someone could please offer some advice/suggestion on this, I would really appreciate it. Best, Naosuke On