Nicolas Williams wrote: > > On Sun, Feb 15, 2009 at 01:21:28AM -0500, Glenn Fowler wrote: > > ast provides its own malloc/free, and those calls are mapped > > to _ast_malloc/_ast_free in the ksh/ast code for opensolaris builds > > so that call to free() in the stack trace was not done directly by > > any ksh/ast code > > I believe this is a bad idea. On Solaris it'd be best to use the global > malloc()/free() from libc (or interposed via pre-loading). > > Rationales: > > - you'll end up with two allocators, which means... > - ...you need to be real sure that some allocation won't be free()ed by > the wrong allocator, and... > - you need to make sure no more than one allocator uses brk()/sbrk(); > - finally, you also prevent use of pre-loaded alternative allocators. > > I strongly recommend that ksh93/AST on Solaris use the standard > allocator, OR, if you insist on having a private allocator, that it > provide an allocator with standard names, so that: a) it interposes upon > libc's, b) remains interposable.
The problem with |libc::malloc()| was that it isn't useable in ksh93's case: 1. |libc::malloc()| suffers from excessive fragmentation issues for long-running scripts. It simply doesn't stop growing the heap. 2. |libc::malloc()| is _slow_ as molasses 3. |libc::malloc()| cannot be used in signal handlers while the AST version allows this A while aho when I was in MPK there was a discussion whether it would make sense to rip-out the existing |libc::malloc()| and port the libast implementation over to libc. The only problem so far was finding enougth free time to do it... ;-( > Incidentally, private allocators have helped find RLTD bugs, so they've > been useful in that sense, but that's about it. 6778453 comes to mind. Uhm... see above... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;)
