[LLVMdev] JIT allocates global data in function body memory

Reid Kleckner rnk at mit.edu
Mon Jun 29 19:23:38 PDT 2009


> 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




More information about the llvm-dev mailing list