llvm dev - Jul 2011 - [LLVMdev] [MCJIT] Why does it allocate function by function?

I am implementing ELFObject class for MCJIT to be able to run ELFs on 
ELF-platforms.

One thing bothers me: I see that the RTDyldMemoryManager-based allocator 
is always passed to MCJIT and to RuntimeDyld classes from outside. This 
enforces the approach that memory will be allocated function by function 
with startFunctionBody/endFunctionBody. This maybe was good for the old 
JIT, but not for MCJIT.

For ELF for example this isn't right. ELF is designed to be loaded into 
memory as a whole. I don't know much about MachO, but most likely it 
should be normally loaded into memory by OS in one block too, as a 
consequence of efficiency considerations.

So is this a design flaw that should be fixed? Or am I missing something?

I think I can lower the allocator from MCJIT into inside of RuntimeDyld. 
So at least ELF will be able to use the bulk allocator. But I though I 
ask here first.

Thank you,
Yuri

On Jul 5, 2011, at 6:04 PM, Yuri wrote:
> I am implementing ELFObject class for MCJIT to be able to run ELFs on
ELF-platforms.
> 
> One thing bothers me: I see that the RTDyldMemoryManager-based allocator is
always passed to MCJIT and to RuntimeDyld classes from outside. This enforces
the approach that memory will be allocated function by function with
startFunctionBody/endFunctionBody. This maybe was good for the old JIT, but not
for MCJIT.
> 
> For ELF for example this isn't right. ELF is designed to be loaded into
memory as a whole. I don't know much about MachO, but most likely it should
be normally loaded into memory by OS in one block too, as a consequence of
efficiency considerations.
> 
> So is this a design flaw that should be fixed? Or am I missing something?
> 
> I think I can lower the allocator from MCJIT into inside of RuntimeDyld. So
at least ELF will be able to use the bulk allocator. But I though I ask here
first.

Hi Yuri,

You're correct that the current JITMemoryManager interface isn't a very
good fit for the MCJIT. For the time being though, the intent is to work with it
as much as possible so that the MCJIT can be a drop-in replacement for the old
JIT. If we change the JITMemoryManager API right off the bat, we'll make it
that much harder for clients to migrate to the new JIT, slowing adoption and
reducing testing. If we run into situations where it's just unreasonable to
do that, we'll need to re-evaluate, but at least for basic things, it should
be reasonably feasible.

Regards,
-Jim

On 07/06/2011 08:28, Jim Grosbach wrote:
> Hi Yuri, You're correct that the current JITMemoryManager interface 
> isn't a very good fit for the MCJIT. For the time being though, the 
> intent is to work with it as much as possible so that the MCJIT can be 
> a drop-in replacement for the old JIT. If we change the 
> JITMemoryManager API right off the bat, we'll make it that much harder 
> for clients to migrate to the new JIT, slowing adoption and reducing 
> testing. If we run into situations where it's just unreasonable to do 
> that, we'll need to re-evaluate, but at least for basic things, it 
> should be reasonably feasible. Regards, -Jim 
I see your point about MCJIT adoption.
But instead of simply fulfilling relocations and finding exported symbol 
locations, now we have to copy each function into the separate location? 
What if it they have the hardcoded assumptions that they are located 
with particular offsets against each other? This is quite clumsy and 
unreasonably complex approach.

I think the right and simple solution would be to make the allocators an 
internal affair of JIT, so that old JIT defines and uses 
JITMemoryManager inside as it needs, and MCJIT doesn't, and clients 
don't see any of this.

Yuri