llvm dev - Jul 2009 - [LLVMdev] JIT allocates global data in function body 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
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

On Jul 1, 2009, at 9:57 AMPDT, 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.
I've asked Evan to look at your patch; I really haven't looked at that  
area since I put that patch in, and he knows it better.

Apple's security restrictions are annoying at time, trust me, I know.   
It's not the decision of anybody working on LLVM.

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

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

Thanks,

Evan

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