Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 15 Jan 2006 03:34:39 -0600 (CST)
From:      Mike Silbersack <silby@silby.com>
To:        Jason Evans <jasone@FreeBSD.org>
Cc:        cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/lib/libc/stdlib malloc.c
Message-ID:  <20060115033212.J97016@odysseus.silby.com>
In-Reply-To: <EDDCE13D-B4EF-450A-B889-AB50CB70D8D5@FreeBSD.org>
References:  <200601121809.k0CI9QGV028693@repoman.freebsd.org> <AD9B1A12-47F1-4EA1-B270-CC83D3149543@freebsd.org> <20060112182804.GA1047@flame.pc> <20060113012900.GA16082@flame.pc> <554CC8A8-35FB-424A-B883-505C26ECBBE8@FreeBSD.org> <20060114213238.GA15253@flame.pc> <6FD0F2BA-88E3-4E82-A5F8-D89051AEEECA@FreeBSD.org> <43C97BCA.6030201@gmail.com> <20060115013248.GA28047@flame.pc> <43C9BDE3.8030408@gmail.com> <20060115032810.GA99817@flame.pc> <EDDCE13D-B4EF-450A-B889-AB50CB70D8D5@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help

On Sun, 15 Jan 2006, Jason Evans wrote:

> On amd64, jemalloc uses mmap() to get chunks of memory to carve up.  It's 
> possible that these chunks are above 4 GB, which means that the high bits are 
> important, but sizeof(int) is 4, not large enough to store such a pointer. 
> With sbrk(), the addresses are rather small, so the high bits would never be 
> used in that case.  This bug would slip by with most (all?) other allocators, 
> and would also slip by jemalloc if USE_BRK were defined for amd64 in 
> malloc.c.
>
> Jason

It's probably more work than you want to do, but it'd probably be really 
helpful if you could rig up a patch to make phkmalloc in 6.x have the 
feature that all allocations go above 4GB.  That way you could call for 
wide testing with that flag enabled, and the ports bugs of this type can 
be shaken out without people blaming jemalloc in -current.

Mike "Silby" Silbersack



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060115033212.J97016>