llvm dev - Jul 2009 - [LLVMdev] JIT allocates global data in function body memory

> 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 it so other models work as well, go ahead.
Maybe what I should do then is change
TargetJITInfo::allocateSeparateGVMemory to allocateGVsWithCode and
invert the meaning, since I feel like most users probably just want
malloc or something similar.  You could then subclass the appropriate
TJI class and override that method.  Would that be a reasonable API
change?  No one else calls or overrides that method.  In order to do
that we'd also need to hear from Evan about why Apple ARM needs to use
malloc.

Is it worth allocating global data through the memory manager, or is
better to use malloc?  Currently global data lives forever (or rather,
as long as the JIT does, which makes sense since they live forever in
a statically compiled program), so I was thinking it might be good for
memory usage and locality to put small globals together into a buffer
similar to the function stub buffer.  That way you don't call malloc
for every global int64, and you can lay them out sequentially in
memory.  Large global arrays should probably get their own block.

Reid

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
>> that environment.  So that model needs to continue to work.  If you
>> want to generalize it so other models work as well, go ahead.
>
> Maybe what I should do then is change
> TargetJITInfo::allocateSeparateGVMemory to allocateGVsWithCode and
> invert the meaning, since I feel like most users probably just want
> malloc or something similar.  You could then subclass the appropriate
> TJI class and override that method.  Would that be a reasonable API
> change?  No one else calls or overrides that method.  In order to do
> that we'd also need to hear from Evan about why Apple ARM needs to use
> malloc.
>
> Is it worth allocating global data through the memory manager, or is
> better to use malloc?  Currently global data lives forever (or rather,
> as long as the JIT does, which makes sense since they live forever in
> a statically compiled program), so I was thinking it might be good for
> memory usage and locality to put small globals together into a buffer
> similar to the function stub buffer.  That way you don't call malloc
> for every global int64, and you can lay them out sequentially in
> memory.  Large global arrays should probably get their own block.
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).

Andrew

> 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