[EMAIL PROTECTED] wrote: > > > Could you try an experiment and compile you sources with > > /usr/lib/libast.so.1 (you need to compile the sources with > > -I/usr/include/ast before /usr/include/ since libast uses a different > > symbol namespace and cannot be used to "intercept" other > > |malloc()|/|free()| calls like libbsdmalloc) ? AFAIK that should cure > > the performance problem (assuming the library functions which heavily > > use |malloc()|/|free()| are compiled against libast headers, too) ... > > What would this experiment prove?
It may result in a more or less real-world benchmark whether this is usefull in general, e.g. whether an ARC contract for libast's malloc vs. libxml2 would be an option. > The test program links to libxml2, > libz, libm, and libc. It seems like it would be a lot of work to > re-compile all of these libraries against libast headers just for > amusement. In the case of libc, I'm not even sure it's possible. Erm... AFAIK you only need to re-compile libxml2 with libast's malloc version. > If libast has its own memory allocator, it would make a lot more sense > to move that functionality into an interposition library like we already > do for libumem, libmapmalloc, libwatchmalloc, libmtmalloc, and > libbsdmalloc. Technically there was an discussion on the last OpenSolaris.org summit to check whether it may sense to replace libc's malloc implementation with the libast one since it's faster, works better with small allocations, scales better up to very large memory allocations, avoids fragmentation for long-running application (something which hit FireFox+Mozilla/Seamonkey and other applications _badly_), has builtin libumem-like memory checking functionality and is async-signal safe (not the one currently in OS/Net, that was a new development for the one which the ksh93-integration update1 will deliver). The only problem so far was that I didn't had time to take a look yet... ;-( ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL <currently fluctuating> (;O/ \/ \O;) _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
