[LLVMdev] JIT allocates global data in function body memory

[Andrew Lenharth]

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