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

[Shuxin Yang <shuxinyang dot oss at gmail dot com>]

Hi,  Florian:

   Could you please elaborate bit more about the "traditional way"?

   An alternative solution I could imagine is to raise the end of
heap (the end close to bss, not the one pointed by sbrk(0)), in an 
attempt to reserve space under 2G. Any idea how to  achieve this goal? I 
played with link-script by changing symbol "_end", but no luck. I wonder 
if address-randomization (https://lwn.net/Articles/569635/) expose some 
interface for this purpose.

Thanks

Shuxin


On 9/8/16 3:02 AM, Florian Weimer wrote:
> >   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