[LLVMdev] JIT allocates global data in function body memory
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.
+#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
> 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.
> 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
>> 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
>> I'd like to get some guidance on what's acceptable before I send a
>> patch to llvm-commits, though.
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
More information about the llvm-dev