David Powell wrote: > > > I think this is more in the range of megabytes since the kernel is full > > of duplicate strings. > > > > Quick look at the problem (kernel only): > > -- snip -- > > # scan all kernel files and dump all strings (or things which look like > > strings) > > $ cat $(find /kernel /usr/kernel /platform -type f) | strings -a | wc -c > > 15951405 > > # scan all kernel files for string-like stuff and remove duplicates > > $ cat $(find /kernel /usr/kernel /platform -type f) | strings -a | sort > > -u | wc -c > > 5342818 > > $ bc -l > > (15951405-5342818) / (1024 * 1024) > > 10.11713695526123046875 > > -- snip -- > > In theory we could save ~~10.1MB in the kernel (userland is likely much > > worse). > > I think you'll find that number goes down considerably if you only > count a single kernel.
Uhm... right. I just checked my VMware B51 installation - the machine is 32bit but I still have 64bit kernel bits installed... weired (well, actually it's good since (in theory) I could use this to boot the VM in either 32bit or 64bit mode (which doesn't work in real life... ;-( )) ... ;-( > Most people don't run both 32 and 64 bit > kernels on x86, nor do people run multiple platforms' kernels > simultaneously on SPARC. And I, for one, only use a fraction of the > drivers installed on my system. .conf files with their large > copyright header are particularly redundant, and they're included in > your figure as well. Right... the numbers were totally useless thanks to the inclusion of the *.conf files... sorry... ;-( > > Note that "strings -a" lists lots of garbage which isn't really strings > > which means the number will be below 10.1MB. Another limiting factor is > > that we cannot fold multiple string literals across module borders but I > > guess we can still save 3-5MB minimum. > > Yes, that will reduce the number further. > > I won't disagree that -xstrconst, methodically deployed, is a good > idea, Well, my idea was to solve the problem in the compiler _first_ (e.g. make "-xstrconst" the default for Sun Studio 12 and add a "-xstrnoconst" option for backwards-compatibilty to older sources) since this is the much more important problem for all applications compiled with Sun Workshop/Forte/Studio and then fix the OS/Net codebase. > but sensational claims of memory savings (which defy > common-sense [1]) aren't going to win people over. Why not actually > try it and measure? It's already on my ToDo list once the first ksh93-integration putback is done... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
