Re: Difference in malloc's behavior in 6.0

[David Laight <david%l8s.co.uk@localhost>]

On Tue, Dec 04, 2012 at 11:04:22PM +0530, Mayuresh wrote:
> lang/gprolog had an issue, due to which it was not working on NetBSD 6.0.
> 
> I know gprolog worked on NetBSD 4.0.
> 
> Have not tried / can't confirm about 5.x.
> 
> It worked on Linux.
> 
> 
> Daniel Diaz, creator and maintainer of gprolog, fixed the issue and he
> informed the following about the issue:
> 
> "NetBSD's malloc seems to have changed. In gprolog we use tagged pointers.
> So we have to use 3 bits of the pointers. On 32 bits machine, we use
> 4-bytes alignement so we can use the 2 least significant bits (b1 and b0).

The memory returned by malloc() ought to have better alignment than
4 bytes - even on most 32 bit systems.
I'm not actually sure what alignment netbsd'd libc malloc() returns though.
16 byte alignment (for items over 16 bytes) would be needed by some code.
(32 byte alignment is needed for AVX - but the kernel doesn't support that).

> The last bit used is the most significant one (b31). Classically, malloc
> (sbrk) does not return data with this bit set to 1 but some implementation
> does (it occurs often when malloc relies on mmap to allocate memory).

Code that relies on that is rather broken.

> So I fixed this using the dl_malloc (Doug Lea malloc)."
> 
> Can somebody throw some light on this change in behavior of malloc,
> whether it was intentional and its purpose etc.

I don't know the justification for using mmap() instead of sbrk().
It may well have given better performance, and certainly has fewer
issues with process address fragmentation.

        David

-- 
David Laight: david%l8s.co.uk@localhost