[LLVMdev] JIT allocates global data in function body memory

Evan Cheng evan.cheng at apple.com
Thu Jul 2 15:09:46 PDT 2009

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  
+  // with garbage.  This parameter is useful for testing and debugging.
+#ifdef NDEBUG
+#define POISON true
+#define POISON false



On Jul 1, 2009, at 11:48 AM, Evan Cheng wrote:

> 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 relocation since relocation is done by the JIT.
> That can be changed, of course.
> 2. There is a hook to change the behavior, i.e. allocating GV
> separately with malloc. The API is not fully flushed out so it's done
> with malloc (which is how it was done before #1).
> 3. We *can* consider changing the default. But we need to do it
> gently. I'd prefer to complete the API to support both models and
> *then* consider making the change. We do not want to disrupt existing
> clients.
> 4. Most *real* implementation should use its down custom memory
> manager. The default manager (or malloc for GVs) works for lli. But
> that's a command line tool for testing, it isn't necessarily how
> things must be done.
> I am glad to see the push to design and implement a proper API to
> support both models. I intend to review the code later today. Sorry
> about the delay.
> Evan
> On Jul 1, 2009, at 9:57 AM, Reid Kleckner wrote:
>>> 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
>> allocateGlobal method would probably allow them to trap it and also
>> send it over the wire, but they say they don't want to make any code
>> changes.
>> I'd like to get some guidance on what's acceptable before I send a
>> patch to llvm-commits, though.
>> Reid
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

More information about the llvm-dev mailing list