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