Date: Fri, 22 Sep 1995 08:40:13 -0500 From: Rich Murphey <rich@lamprey.utmb.edu> To: asami@cs.berkeley.edu Cc: nate@rocky.sri.MT.net, roberto@keltia.Freenix.FR, nate@rocky.sri.MT.net, freebsd-current@FreeBSD.org Subject: Re: XFree86 and the new malloc Message-ID: <199509221340.IAA04437@id.slip.bcm.tmc.edu> In-Reply-To: <199509221249.FAA27600@silvia.HIP.Berkeley.EDU> (asami@cs.berkeley.edu)
next in thread | previous in thread | raw e-mail | index | archive | help
|From: asami@cs.berkeley.edu (Satoshi Asami) | |Don't know if Rich is listening to -current, so let me comment on this. | | * Basically, the stock BSD malloc caused a number of programs to be less | * useful than they were if compiled against GNU malloc. |The largest (literally) example was the X server. My 3.1.1 XF86_S3 in |16-bit mode routinely grew over 20MB and it was, um, very annoying, to |say the least. With gnumalloc, it rarely goes over 10MB. Ditto for |xv. With the old libc malloc, there really wasn't much choice but to |use gnumalloc. Looking back.. In XFree86 2.x there were reports of -lgnumalloc breaking the server, but these have long since been fixed so that -lgnumalloc is what is used now in XFree86 3.1.x. In 3.0 we still used -lmalloc becuse it was faster than -lgnumalloc on smaller allocations and equally fast on large allocations. But there was strong interest in saving memory using gnumalloc and the switch was made after 3.0. Caveat: If you exit the clients in a FIFO order, the system get's all the memory back, but otherwise gnumalloc leaves holes which are't returned. |We'll have to test how phkmalloc works, and see what we should |recommend them for 3.1.3 (or 3.2?). I'm going to compile the X server |with phkmalloc tomorrow (I'm doing a make world now) and let you guys |know if something goes "puff" or "bloat". OK, I'll start building XFree86 alphas and betas with phkmalloc as well. If there are no complaints we can make it the default for XFree86. Rich
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509221340.IAA04437>