Nicolas Williams wrote: > On Wed, Feb 18, 2009 at 07:42:29PM +0100, Roland Mainz wrote: > > Nicolas Williams wrote: > > > 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. > > I am not sure that's true, but you should try libumem -- if it works > then link with libumem. If no Solaris allocator works well enough then > use your own BUT DO NOT prefix the symbol names with _ast_ or anything > else -- let your allocator interpose on the system one so as to avoid > multiple allocators in one process.
AFAIK this will not work properly if someone uses libumem via LD_PRELOAD since libumem&co. are not async-signal safe and ksh93 relies on this feature. [snip] > In this case keep your allocator BUT DROP THE PREFIX (i.e., let it > interpose on libc's. Doing that would cause the shell to crash in some conditions - see above. > > 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... ;-( > > I think I'd rather see libumem replace the default allocator. Erm... libast's allocator and libumem have similar debugging features while libast AFAIK avoids fragmentation better and is async-signal safe. Maybe we should do some kind of hybrid with libast's algorithm and libumem's debugging features... > > > 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... > > Er, what? I was trying to point out that the "...but that's about it ..." is IMO not correct - custom allocators may make sense if they have extra features or prevent the application acting in an undesireable way (for example performance or excessive heap consumption caused by fragmentation (I don't remeber the bugid but somewhere at bugs.mozilla.org is an evaluation of the various |malloc()| implementation and the Solaris libc one wasn't exactly one of the better ones (only the Win32 implementation was worse... ;-/ ))). ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;)
