[PATCH] Initialize memory groups once any is initialized.
Dana Koch via llvm-commits
llvm-commits at lists.llvm.org
Fri Jul 17 11:47:42 PDT 2020
Please commit on my behalf. Thanks!
On Mon, Jul 13, 2020 at 4:28 PM Lang Hames <lhames at gmail.com> wrote:
>
> Hi Dana,
>
> Thanks for your patience. This looks good to me. Do you have commit access, or would you like me to commit on your behalf?
>
> Regards,
> Lang.
>
>
>
> On Mon, Jun 29, 2020 at 1:20 PM Dana Koch <dsk at google.com> wrote:
>>
>> JITted code may include relocations between sections, and the
>> relocations often chosen to do this are 32-bit PC-relative relocation
>> types. Thus, consideration must be made to ensure sections are allocated
>> sufficiently close to one another.
>>
>> The SectionMemoryManager provides three memory groups, one for Code
>> data, one for ROData, and one for RWdata. Sections are allocated with
>> mmap (via allocateMappedMemory) which allows the caller to provide a
>> hint to the system to suggest where to position mmap'ped memory. A
>> memory group has a Near block which lets successive allocations to that
>> memory group be positioned near other mappings in that group via the
>> mmap hint. Initially, this Near block is empty, that is, its address is
>> nullptr. When mmap is passed a nullptr hint, the system may choose any
>> location to position the mapping.
>>
>> This means, prior to this commit, the first Code section mapping, ROData
>> section mapping, and RWData section mapping will all be placed at a
>> location of the system's choosing, and the system may choose distant
>> enough locations in memory such that a 32-bit PC-relative relocation
>> would overflow.
>>
>> Therefore, once allocateMappedMemory allocates the first mapping, copy
>> that Near block hint to the other memory groups. This ensures that
>> sections are allocated close to another so relative relocations are less
>> likely to overflow.
More information about the llvm-commits
mailing list