[LLVMdev] [MCJIT] Why does it allocate function by function?

[Jim Grosbach]

On Jul 6, 2011, at 9:28 AM, Yuri wrote:

> 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.

That would be malformed input to the JIT. It's a requirement, as it currently stands, that functions be locatable individually. If a back end doesn't support that, then each function should be split into a separate Module (and thus object file) and submitted to the JIT separately. I fully acknowledge this is not always possible for all objects for arbitrary bitcode input (string tables and static functions come to mind). We're

I agree the approach is not optimal. If we were designing completely from scratch, I would absolutely do it differently. We're not, however, and can't simply throw away what we have and start over without significant pain. It's better to  instead work incrementally. The first step is to implement with the current interfaces and get the MCJIT non-trivially functional. There are a lot of problems we can solve without needing to tackle the memory manager right off the bat. Doing so will also give us better insight into what the eventual design of the memory manager should be. That way we improve our chances of getting the design done more cleanly and not having to refactor it yet again later.

> 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.

I don't follow. How can the clients not see it? They define their own memory managers and pass them into the JIT. See LLDB for an example.

-Jim