free() does not physically trim/reclaim memory

Florian Weimer fweimer@redhat.com
Thu Sep 8 10:02:00 GMT 2016


On 09/02/2016 06:27 PM, shuxin yang wrote:
> Hi, Florian:
>
> On 09/02/2016 04:44 AM, Florian Weimer wrote:
>> On 09/01/2016 08:24 PM, shuxin yang wrote:
>>>     In my application, I need to call mmap() a block right after BSS in
>>> order to prevent heap from growing.
>>
>> You cannot rely that this has any observable effect.  Why do you need
>> to do this?
>
>   Our application embeds luajit. Due to some limitations, luajit
> allocates object under 2G;
> on x86-64 platform, it is done by calling mmap() with flag MAP_32BIT and
> then cutting
> a block out of it. We need to preserve the space (BSS-end, 2G] for
> luajit. That is why
> we need to mmap() a tiny block right after BSS right before the main()
> function of the application
> is entered.

Ahh.  The traditional way (which is also more foolproof) is to map the 
heap at process startup using PROT_NONE, and carve out bits from that as 
needed using mprotect.  This will also help if, for whatever reasons, 
some other library attempts to allocate memory in the lower 32-bit range.

Funding 48-bit pointers or scaled pointers for x86_64 LuaJIT might be a 
better approach, though. :)

Florian



More information about the Libc-help mailing list