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>