From owner-cvs-src@FreeBSD.ORG Sun Jan 15 09:34:44 2006 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 73BA016A423 for ; Sun, 15 Jan 2006 09:34:44 +0000 (GMT) (envelope-from silby@silby.com) Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by mx1.FreeBSD.org (Postfix) with SMTP id 3BE6A43D4C for ; Sun, 15 Jan 2006 09:34:40 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 58177 invoked from network); 15 Jan 2006 09:34:38 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 15 Jan 2006 09:34:38 -0000 X-pair-Authenticated: 209.68.2.70 Date: Sun, 15 Jan 2006 03:34:39 -0600 (CST) From: Mike Silbersack To: Jason Evans In-Reply-To: Message-ID: <20060115033212.J97016@odysseus.silby.com> References: <200601121809.k0CI9QGV028693@repoman.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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/libc/stdlib malloc.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2006 09:34:44 -0000 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