Re: free() does not physically trim/reclaim memory

[Florian Weimer <fweimer at redhat dot com>]

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