tale@PAWL.RPI.EDU (David C Lawrence) (05/12/89)
I forgot to mention one other significant advantage of shared
libraries in my posting and I will be really surprised if no one
points this out ... with shared libraries, every programme that used
them gets a bugfix automatically without the need to recompile. That
is certainly a plus. And as jr pointed out (in mail), space is also
larger in memory for static programmes than dynamic ones.
Dave
--
(setq mail '("tale@pawl.rpi.edu" "tale@itsgw.rpi.edu" "tale@rpitsmts.bitnet"))
(error "UUCP not spoken here. Long bang paths unlikely to get mail replies.")david@elroy.Jpl.Nasa.Gov (David Robinson) (05/13/89)
In article <8905121552.AA04949@pawl.rpi.edu>, tale@PAWL.RPI.EDU (David C Lawrence) writes: > I forgot to mention one other significant advantage of shared > libraries in my posting and I will be really surprised if no one > points this out ... with shared libraries, every programme that used > them gets a bugfix automatically without the need to recompile. That > is certainly a plus. And as jr pointed out (in mail), space is also > larger in memory for static programmes than dynamic ones. I seem to have missed the first part of this so I will assume that the question was "Why doesn't (or can't) emacs use shared libraries under SunOS 4.0. Well I have just finished beta testing a version of 18.53 that uses shared libraries and an mmap'd data segment and bss instead of unexec(). I claim that this will use less real memory than an unexec'd emacs, I have even had one tester claim improved performance, this has not been verified but is possible on machines with limited memory. As soon as I get the patches up to 18.54 I will send them in to GNU, it sounded like emacs was frozen for version 18 and all work was going into version 19, if true I will post the diffs to this list in addition. [They are fairly small] -David -- David Robinson elroy!david@csvax.caltech.edu ARPA david@elroy.jpl.nasa.gov ARPA {cit-vax,ames}!elroy!david UUCP Disclaimer: No one listens to me anyway!
rms@AI.MIT.EDU (05/13/89)
I would install simple changes to make Emacs support shared libraries on non-GNU kernels, but I will not spend a lot of time on them. I expect the GNU kernel to have some form of shared libraries, but it is too soon to know what their interface will be. There is no reason to suppose that the peculiarities will be the same as in various other systems today. So it would be premature to do any work for their sake.
pinkas@hobbit.intel.com (Israel Pinkas ~) (05/15/89)
In article <152@talarian.UUCP> scott@talarian.UUCP (Scott Weitzenkamp) writes: > I noticed that on SunOS 4.0, GNU emacs uses the -Bstatic flag to cc > to prevent the use of shared libraries. Does GNU emacs ever use > shared libraries? If not, why not? Does System V have an option > like -Bstatic to prevent the use of shared libraries? I posted about this before, but I realized that there was one more thing to consider. Efficiency. SunOS 4.0 executables do not swap text pages by default (-z flag to ld). They are released from memory and marked as not present. If needed again, they are loaded from the disk image. If the original image is on an NFS mounted partition, every page fault results in an NFS access. This hurts performance on large processes. (We improved performace on our X10 server by linking with -n by 100%.) Two other problems with this demand paging are: 1) If the file server becomes unavailable (crashes, times out, etc.) the page fault can fail and the process can hang. The network is flooded with NFS requests, which slows down everybody. 2) If the image is deleted, everything goes haywire. This can happen with any type of demand paging, but the type in SunOS 4.0 just exacerbates the problem, becaus the same page can be loaded many times. (I know, this is stupid, but it happens occasionally. I didn't think that anybody would leave an Emacs process around for more than a week, but guess what?) The above are both problems with NFS, but dynamic libraries just add to the confusion. -Israel -- -------------------------------------- Disclaimer: The above are my personal opinions, and in no way represent the opinions of Intel Corporation. In no way should the above be taken to be a statement of Intel. UUCP: {amdcad,decwrl,hplabs,oliveb,pur-ee,qantel}!intelca!mipos3!cadev4!pinkas ARPA: pinkas%cadev4.intel.com@relay.cs.net CSNET: pinkas@cadev4.intel.com
jr@bbn.com (John Robinson) (05/16/89)
In article <PINKAS.89May14180259@hobbit.intel.com>, pinkas@hobbit (Israel Pinkas ~) writes: >SunOS 4.0 executables do not swap text pages by default (-z flag to ld). >They are released from memory and marked as not present. If needed again, >they are loaded from the disk image. If the original image is on an NFS >mounted partition, every page fault results in an NFS access. This hurts >performance on large processes. This depends on your configuration. If your swap device is remote via ND or NFS, swapping a page results on two network accesses. And ND is more costly than NFS to boot. >1) If the file server becomes unavailable (crashes, times out, etc.) the >page fault can fail and the process can hang. The network is flooded with >NFS requests, which slows down everybody. I don't think you can do much better than this with a diskless node. To minimize your exposure, your executables and swap area should be provided by the same server. I don't know whether NFS or ND behaves worse when the server croaks. >2) If the image is deleted, everything goes haywire. Whoa. My understanding has always been that you can unlink a file, but its inode stays around until every open FD on it is closed. You are implying that NFS breaks this behavior? Seems to me that Unix would have a hard time living with this change. >(I didn't think that anybody would >leave an Emacs process around for more than a week, but guess what?) Sho nuff. Do it all the time. -- /jr jr@bbn.com or bbn!jr C'mon big money!