Monitoring process startup, I noticed libxpcom.so dlopen'ing libdemangle.so.1 via it's .init section. Why can't this be a standard dependency? or even better, couldn't this dlopen be deferred until the demangling library is needed? This is where I start talking about defferred loading. If you have to load a lot of objects, is it possible to load them when you need them, rather that all up front incase you need them? After we've loaded the process and fired the initial .init's, ld.so.1 reveals a whole bunch of unreferenced dependencies (as ldd did above), and more importantly some unused: 00496: 1: file=libjsj.so unused: does not satisfy any references. 00496: 1: file=libplc4.so unused: does not satisfy any refe 00496: 1: file=libgtk-1.2.so.0 unused: does not satisfy any refere 00496: 1: file=libgmodule-1.2.so.0 unused: does not satisfy any re 00496: 1: file=libXext.so.0 unused: cyclic group [3] member: unreferen 00496: 1: file=libX11.so.4 unused: cyclic group [3] member: unreferenc 00496: 1: file=libm.so.1 unused: does not satisfy any references 00496: 1: file=librt.so.1 unused: does not satisfy any references 00496: 1: file=libmp.so.2 unused: does not satisfy any references 00496: 1: file=libaio.so.1 unused: does not satisfy any references 00496: 1: file=libmd5.so.1 unused: does not satisfy any references If you follow my advice in A, some of this might disappear. But an additional technique is to use lazy-loading. Build your objects with -zlazyload and then any dependencies will only be loaded when a symbolic reference is made to them. This lazy-loading has the effect of sharing the cost of loading objects throughout the process lifecycle, rather than bearing all the costs up front.

Our linker expert suggests us to add these two options in the LDFLAGS. This is for improving performance

Hi seawood@netscape.com: Can you give me a r= for the above patch please? I have put the flag in the place where it should only affect Solaris non-gcc (i.e., using Sun's compiler) builds. Thanks, Margaret

Comment on attachment 89156 [details] [diff] [review] Patch with -lazyload and -zcombreloc option for solaris r=cls

Thanks cls. Didn't get to come back to this until now. Who should I be asking for sr= these days? Margaret

Per http://www.mozilla.org/hacking/reviewers.html, r=cls should be all you need to check into the build system files. You can ask leaf for sr= if you really feel the need for a second review. :)

Great. I am not going to bother leaf if I don't have to. I just think that the process requires that. Glad to know that it doesn't. I'll check it in soon. Thanks, Margaret

Tinderbox says that it is frozen for 1.1beta, I guess I'll wait till next week for checkin then.

I did some test builds on Solaris 2.7/SPARC with Sun Workshop 7/FCS, the patch seems to cause no problems. ---- Margaret Chan wrote: > Tinderbox says that it is frozen for 1.1beta, I guess I'll wait till next week > for checkin then. It's now frozen for 1.1final... ;-( But I do not see problems with these flags - what about sending an email to drivers@mozilla.org and request approval for the "trunk" ?

Bummer... It seems to be frozen forever... Anyway, just send an email to driver. I'll see what they say. Margaret

Margaret Chan wrote: > Bummer... It seems to be frozen forever... Yeah. Grrrrrrr... xx@@@!!!... ;-( > Anyway, just send an email to driver. Erm... do you mean you will send an email or should I send the request ?

Oops. Excuse my grammar. > Anyway, just send an email to driver. It should say "just sent an email to driver." since I have already done so. I Am currently waiting for a reply from them. Margaret

Comment on attachment 89156 [details] [diff] [review] Patch with -lazyload and -zcombreloc option for solaris a=asa (on behalf of drivers) for checkin to 1.1

Margaret Chan: Please read http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey : -- snip -- "OPEN means that the tree is open only to drivers-approved checkins that have been approved within the three days prior to the checkin." -- snip -- or short: Driver approval is only valid if you check the code "in" ASAP; the approval expires after three days... ... can you check the patch "in" before the a=asa (see comment #12) expires, please ?

Thanks for the reminder, Roland. I just did. Marked it resolved fixed.