Reid Kleckner
2009-Jun-30 02:23 UTC
[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
Andrew Lenharth
2009-Jul-01 16:26 UTC
[LLVMdev] JIT allocates global data in function body memory
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
Reid Kleckner
2009-Jul-01 16:57 UTC
[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
Maybe Matching Threads
- [LLVMdev] JIT allocates global data in function body memory
- [LLVMdev] JIT allocates global data in function body memory
- [LLVMdev] JIT allocates global data in function body memory
- [LLVMdev] JIT allocates global data in function body memory
- [LLVMdev] bug in the JIT global variable emitter