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

[Gasiunas, Vaidas]

Hi Andy,

I ported our patch for the precalculation of size to LLVM trunk and wrote a small unit test for it. The basic idea is that RuntimeDyld after creating ObjectImage, but before loading it notifies the memory manager about the total space required to allocate all sections.

Note that we coded it for our requirements, so it may still need some adjustments to make it general enough for all possible uses. For example, I am not sure what would be the best way to make this calculation of size optional. For example, I could add another virtual method in the memory manager, to ask whether it needs the information about total size. 

BTW do you think we should move further discussion to llvm-commits?

Regards,
Vaidas


-----Original Message-----
From: Kaylor, Andrew [mailto:andrew.kaylor at intel.com] 
Sent: Freitag, 3. Januar 2014 19:13
To: Gasiunas, Vaidas; Philip Reames; LLVM Dev
Subject: RE: [LLVMdev] Making LLVM safer in out-of-memory situations

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: computeTotalAllocSize.patch
Type: application/octet-stream
Size: 7739 bytes
Desc: computeTotalAllocSize.patch
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140109/155dcc9b/attachment.obj>