[LLVMdev] Making LLVM safer in out-of-memory situations

[Kaylor, Andrew]

Hi Vaidas,

Thanks for the feedback.

Regarding the single allocation, I'm not opposed to having an option to pre-calculate the size and provide it in advance to the memory manager.  We actually had an implementation that worked that way once, but it never got checked in because we decided the associated implementation was too complicated to use as the base memory manager.  The pre-calculation will need to be optional so that extra calculation isn't imposed on clients that don't need it.

With your explanation below I understand the issue with function address mapping.  You've probably seen that RuntimeDyld already keeps a map of symbol names to addresses.  My concern with having RuntimeDyld keep the additional information to lookup symbols based on addresses is that MCJIT already consumes more memory than we'd like.  If you can make your implementation work with the ObjectImage that would probably be best.

-Andy

-----Original Message-----
From: Gasiunas, Vaidas [mailto:vaidas.gasiunas at sap.com] 
Sent: Friday, January 03, 2014 4:59 AM
To: Kaylor, Andrew; Philip Reames; LLVM Dev
Subject: RE: [LLVMdev] Making LLVM safer in out-of-memory situations

Hi Andy,

> I would think you could use a simple allocation scheme on the host side and then allocate a single block (or perhaps one code block and one data block) in the target process to receive everything, since everything is loaded on the host before you need to copy it to the target process.  But perhaps I'm missing something regarding your particular scenario.

> In any event, there are good reasons why a memory manager (particularly for local use) might want to know the total size before allocation begins.

We subclass RTDyldMemoryManager interface to implement allocateDataSection and allocateCodeSection. As you know, when RuntimeDyld loads a module, it calls one of these methods for each section. I want that all sections of a module are allocated in one block. One reason is efficiency, another is that 32-bit relocations fail when the blocks are too far from each other.  So we compute the total size of all sections and allocate one block for module and give parts of that block when allocateDataSection and allocateCodeSection are called by the RuntimeDyld.

> I'm not sure I understand the problem you're solving with regard to function addresses.  I do know that there's a shortcoming where the host address isn't directly available after section addresses have been remapped for remote use.  (LLDB will run into that problem when it stops using deprecated functions.)  So I expect a change of some sort will be necessary there.

We need this info when unwinding the call stack in case of a crash. We have to map the program counter to a function name. So we need a simple symbol info that maps from address ranges to function names. When we implemented this functionality, there was no method in the RuntimeDyld to iterate over all loaded functions. In LLVM3.3, though, I see that loadModule returns ObjectImage. So maybe now I could access the symbols directly from ObjectImage, without patching RuntimeDyld. I will try that.

> Are you considering submitting your patches for incorporation into LLVM trunk?

Yes, we would be glad to contribute our patches. I have to retest everything on trunk, because until now we used only the official LLVM3.3 release. 

Regards,
Vaidas

-----Original Message-----
From: Kaylor, Andrew [mailto:andrew.kaylor at intel.com]
Sent: Freitag, 20. Dezember 2013 18:41
To: Gasiunas, Vaidas; Philip Reames; LLVM Dev
Subject: RE: [LLVMdev] Making LLVM safer in out-of-memory situations

Hi Vaidas,

I would think you could use a simple allocation scheme on the host side and then allocate a single block (or perhaps one code block and one data block) in the target process to receive everything, since everything is loaded on the host before you need to copy it to the target process.  But perhaps I'm missing something regarding your particular scenario.

In any event, there are good reasons why a memory manager (particularly for local use) might want to know the total size before allocation begins.

I'm not sure I understand the problem you're solving with regard to function addresses.  I do know that there's a shortcoming where the host address isn't directly available after section addresses have been remapped for remote use.  (LLDB will run into that problem when it stops using deprecated functions.)  So I expect a change of some sort will be necessary there.

Are you considering submitting your patches for incorporation into LLVM trunk?

-Andy

-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Gasiunas, Vaidas
Sent: Friday, December 20, 2013 5:16 AM
To: Philip Reames; LLVM Dev
Subject: Re: [LLVMdev] Making LLVM safer in out-of-memory situations

>> To increase stability for us we have already moved the main part of the compilation to a separate process that may crash in case of an error without doing much harm, i.e. does not crash the database.
> Were there any interesting challenges that arose during this process?  
> This seems to be an approach many folks are either taking or 
> considering.  If there are things we could do to make this easier, it 
> might be worth considering.

After porting our project to LLVM3.1, we realized that we can use the MCJIT architecture to move compilation into a separate process, because it enables loading ELF objects  generated in another process. 
In fact, it worked as expected. It was really an important improvement for our use scenario. 

Maybe what was not so nice is that we had to patch RuntimeDyld to adapt it to our requirements. We had to extend it with a method for computing the total size of memory required for loading all sections required for execution, so that we can allocate one memory block for all sections, and another method to retrieve the address ranges of all loaded functions so that we have a mapping from addresses to function names.

Regards,
Vaidas

-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Philip Reames
Sent: Donnerstag, 19. Dezember 2013 18:32
To: Becker, Philipp; LLVM Dev
Subject: Re: [LLVMdev] Making LLVM safer in out-of-memory situations

On 12/13/13 4:55 AM, Becker, Philipp wrote:
> To increase stability for us we have already moved the main part of the compilation to a separate process that may crash in case of an error without doing much harm, i.e. does not crash the database.
Were there any interesting challenges that arose during this process?  
This seems to be an approach many folks are either taking or considering.  If there are things we could do to make this easier, it might be worth considering.
> Therefore, we've currently concentrating on specific components that still remain in the database process, such as CodeLoader and VMCore, which is used for emitting IR code. Although, of course, we're also interested in increasing the general stability of the whole llvm w.r.t. error situations.
>
Understood.  If you have patches that need reviewed, I'd be happy to help.

Philip
_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev