similar to: [LLVMdev] JIT allocates global data in function body memory

On Jun 29, 2009, at 5:41 PMPDT, Reid Kleckner wrote: > So I (think I) found a bug in the JIT: > http://llvm.org/bugs/show_bug.cgi?id=4483 > > Basically, globals used by a function are allocated in the same buffer > as the first code that uses it. However, when you free the machine > code, you also free the memory holding the global's data. The address > is still in the

On Mon, Jun 29, 2009 at 5:50 PM, Dale Johannesen<dalej at apple.com> wrote: > > On Jun 29, 2009, at 5:41 PMPDT, Reid Kleckner wrote: > >> So I (think I) found a bug in the JIT: >> http://llvm.org/bugs/show_bug.cgi?id=4483 >> >> Basically, globals used by a function are allocated in the same buffer >> as the first code that uses it.  However, when you

On Jun 30, 2009, at 11:18 AMPDT, Jeffrey Yasskin wrote: > On Mon, Jun 29, 2009 at 5:50 PM, Dale Johannesen<dalej at apple.com> > wrote: >> >> On Jun 29, 2009, at 5:41 PMPDT, Reid Kleckner wrote: >> >>> So I (think I) found a bug in the JIT: >>> http://llvm.org/bugs/show_bug.cgi?id=4483 >>> >>> Basically, globals used by a

Dale Johannesen wrote: > On Jun 30, 2009, at 11:18 AMPDT, Jeffrey Yasskin wrote: > >> On Mon, Jun 29, 2009 at 5:50 PM, Dale Johannesen<dalej at apple.com> >> wrote: >>> On Jun 29, 2009, at 5:41 PMPDT, Reid Kleckner wrote: >>> >>>> So I (think I) found a bug in the JIT: >>>> http://llvm.org/bugs/show_bug.cgi?id=4483

Hi LLVM folks, Attached with this email, you will find a patch not directly applicable (it doesn't compile like this) which (try to) enhance the structure of a possible JIT with the MC framework. Basically : - MCJIT : - Main class implementing ExecutionEngine interface - owns and creates : - a MemoryManager (will be a reuse of the JITMemoryManager mechanism) - a MCJITStreamer

On Thu, Jul 2, 2009 at 3:09 PM, Evan Cheng<evan.cheng at apple.com> wrote: > 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? That makes four optional arguments to ExecutionEngine::create. Do you mind if I go ahead and add an

Chris Lattner wrote: > On Mon, 6 Dec 2004, Morten Ofstad wrote: >> I guess what I'd like to know is if the process of spilling constants >> to memory could be a bit more controlled, maybe using the JIT memory >> manager and putting it in with the function stubs? > > Yes, this can and should definitely be improved. If you look at >

> That's me (and I'm not on IRC because I like messages to be > archived).  The reason everything needs to go in the same buffer is > that we're JITting code on one machine, then sending it to another to > be executed, and references from one buffer to another won't work in > that environment.  So that model needs to continue to work.  If you > want to generalize

On Jul 2, 2009, at 5:20 PM, Reid Kleckner wrote: > On Thu, Jul 2, 2009 at 3:09 PM, Evan Cheng<evan.cheng at apple.com> > wrote: >> 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? > > That makes four

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

On Mon, 13 Dec 2004, Morten Ofstad wrote: > I have made a patch along these lines. Although I reused the JITMemoryManager > object, I am allocating constant pools from another block of memory. This > fixes my remaining leaks. It would be nice if also the global variables were > allocated in this way, but it's not needed for my application since I'm > managing that memory

> We have been JITing kernels and having a memory manager for globals > would be a big win there (clean up a few hacks to make things go in > the correct locations). I'm also guessing that Dale's client at Apple is using a custom memory manager, since without doing that there's no way to get the size of the code block in order to send it over the wire. Adding an

Sorry I am late to the thread. I've been meaning to find the time to respond properly. 1. Yes, the default behavior is to keep GV and function in the same memory buffer. The reason is the JIT can be used in a client and server environment. This makes it possible without doing expensive relocation on the fly. In fact, the currently implementation doesn't allow the client to do

YES. My use of LLVM involves an app that JITs program after program and will quickly swamp memory if everything is retained. It is crucial to aggressively throw everything away but the functions we still need to execute. I've been faking it with old JIT (llvm 3.4/3.5) by using a custom subclass of JITMemoryManager that squirrels away the jitted binary code so that when I free the Modules,

Chris Lattner wrote: > On Mon, 13 Dec 2004, Morten Ofstad wrote: > >> I have made a patch along these lines. Although I reused the >> JITMemoryManager object, I am allocating constant pools from another >> block of memory. This fixes my remaining leaks. It would be nice if >> also the global variables were allocated in this way, but it's not >> needed

Hello! Working with LLVM JIT-compiler I found a small bug and I'd like to correct it. Namely, on some tests LLVM fails with message "JIT: Ran out of space for generated machine code!" This error emerges because the test creates big static array. Global variables are placed into memory block for function, that is first seen using given variable. Besides, during memory allocation

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 turn that into machine code using ExecutionEngine::runJITOnFunction. The resulting native code is then installed as the

On Mon, Jun 29, 2009 at 9:23 PM, Reid Kleckner<rnk at mit.edu> wrote: >> That's me (and I'm not on IRC because I like messages to be >> archived).  The reason everything needs to go in the same buffer is >> that we're JITting code on one machine, then sending it to another to >> be executed, and references from one buffer to another won't work in

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

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