scott@talarian.UUCP (Scott Weitzenkamp) (05/12/89)
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? -- Scott Weitzenkamp UUCP: uunet!talarian!scott Talarian Corporation ARPA: farmie@portia.stanford.edu "Welcome to the late show, starring NULL and void" -- Men At Work
tale@pawl.rpi.edu (David C Lawrence) (05/12/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? Two reasons that I can think of: a) debugging is hell on something link edited with shared libraries. b) loadup is slower (often times perceptibly, not just some sort of unnoticeable benchmark thing) when using shared libraries. I am pretty certain that it _can_ be compiled with the libraries (ie, what should prevent it, code-wise), but it isn't. The primary argument for using them is to cut down on size of the application, but the subsequent loss of debugging power and load-up time outweighs that consideration as long as you have the space on your system. Dave -- tale@rpitsmts.bitnet, tale%mts@itsgw.rpi.edu, tale@pawl.rpi.edu
pinkas@hobbit.intel.com (Israel Pinkas ~) (05/13/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? This is because unexec() does not know how to dump executables that were dynamically linked. James Turner (of Daisy) and I spent a lot of time bashing on this one, since we had early releases of SunOS 4.0 on Sun 386i's. (We were both field test sites.) The problem that I had was that there was no predictable way to determine whether the memory image had been dynamically linked. (Nothing documented, that is.) Eventually, I gave up on this, since it really didn't matter to me all that much. I don't know much about SysV, but I suspect that there should be a way. If nothing else works, you can always list the library name on the command line instead of -l<lib>. Remember to add /usr/lib/libc.a, or whatever it is on your machine, at the end of the command line if your machine has a dynamic version of libc. -Israel Pinkas -- -------------------------------------- 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
mac@mrk.ardent.com (Michael McNamara) (05/13/89)
In article <TALE.89May12023656@imagine.pawl.rpi.edu> tale@pawl.rpi.edu writes: |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? | |Two reasons that I can think of: | |a) debugging is hell on something link edited with shared libraries. can be done. | |b) loadup is slower (often times perceptibly, not just some sort of |unnoticeable benchmark thing) when using shared libraries. not really. | |I am pretty certain that it _can_ be compiled with the libraries (ie, |what should prevent it, code-wise), but it isn't. The primary |argument for using them is to cut down on size of the application, but |the subsequent loss of debugging power and load-up time outweighs that |consideration as long as you have the space on your system. | |Dave |-- | tale@rpitsmts.bitnet, tale%mts@itsgw.rpi.edu, tale@pawl.rpi.edu Yes gnu-emacs can be compiled with and using shared libraries on system V. I did the port for the cydra 5 (when cydrome was still in business). The real reason GNU-emacs is distributed with -Bstatic on Sun 4.0 is because no one wanted to fix unexec to understand shared libraries. However, it is definatly possible to make unexec work with shared libraries. It is also possible to work around unexec in another way: David Robinson, at NASA Ames, has distributed diffs for gnu-emacs that: "Below are the diffs to 18.53 to implent GNU emacs under SunOS 4.0 using mmap() instead of unexec() and to also allow for shared libraries. A couple of installation notes, after temacs finishes preloading the lisp code it dumps the output into "xemacs.map" in the current directory. This file must be renamed to PATH_EXEC/emacs.map for normal use. If you wish to test the code out without moving the map file you can run "xemacs -map xemacs.map" for testing. Included in diff format are two new files, s-sunos4map.h and sunmap.c, if you are using "patch" they should be extracted with no problem. If you don't have patch (hard to believe) you can simply cut and paste them." You should send mail to David, as he has been working on this and I am sure has newer versions that what I have. He can be reached at: david@ames.arc.nasa.gov -mac _________________ Michael McNamara mac@ardent.com
david@elroy.Jpl.Nasa.Gov (David Robinson) (05/13/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 have implemented a version of GNU emacs that uses shared libraries. The reason it didn't before was that emacs calls unexec() to save the data segment and bss segment, in these segments are information about where libraries are mmap'd in if you compile it with shared libraries. This information is not always the same and will definately differ on different machines. There are other problems as well. My version that uses shared libraries does so by writing out the data and bss segments to a file and mmap'ing it in upon execution. This file is mmap'd in as a copy-on-write segment so that only the pages that are changed will be copied and the rest shared. This should reduce the amount of physical memory needed when more than one copy is running and help out Suns with limited memory. I will be sending the patches to implement this to GNU as soon as I get them upgraded to the latest version of emacs. -- 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!
gandalf@csli.Stanford.EDU (Juergen Wagner) (05/13/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? The main reason is the way in which GNUemacs binaries are created: you start an "empty" Emacs which loads all necessary files, and then a core image of Emacs with preloaded files is created. This core image is converted to an executable program, and that's what you fire up as GNUEmacs. The problem with this process is that if you save the core image, all routines have to be resolved, i.e. the resulting image will not support dynamic linking. [I haven't built Emacs in a while, so things might have changed.] -- Juergen Wagner gandalf@csli.stanford.edu wagner@arisia.xerox.com
guy@auspex.auspex.com (Guy Harris) (05/13/89)
>I don't know much about SysV, but I suspect that there should be a way. If >nothing else works, you can always list the library name on the command >line instead of -l<lib>. Remember to add /usr/lib/libc.a, or whatever it >is on your machine, at the end of the command line if your machine has a >dynamic version of libc. I seem to remember something that indicated that with S5R3 shared libraries you had to explicitly tell "cc" to link with shared libraries; you'd have to do "cc ... -lc_s" to link with the shared C library. (S5R4 shared libraries will probably bear a startling resemblance to SunOS 4.x shared libraries....)
mike@thor.acc.stolaf.edu (Mike Haertel) (05/13/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? It is very hard to make a program that has the capability of `undumping' itself (i.e., creating a new executable file which when started will restore the current state of the program) work with most shared library implementations. The problem is that the shared library generally has its own separate `data segment' which is obtained from the library on program startup, not from the executable file. The library's data segment generally contains interesting things such as the state of the I/O library and the memory allocator, stuff that you need to preserve if you're going to undump. It's certainly possible to do such an undump, and I can also visualize various shared library implementations that would make it straightforward, but they would probably less efficient in the general case. On, say, a Sunos 4 machine, the library code probably comprises less than 40K of the emacs executable anyway. It just isn't worth the effort. -- Mike Haertel <mike@stolaf.edu> main() ??< printf("hello, world??/n"); ??>
david@elroy.Jpl.Nasa.Gov (David Robinson) (05/14/89)
In article <6443@ardent.UUCP>, mac@mrk.ardent.com (Michael McNamara) writes: > It is also possible to work around unexec in > another way: David Robinson, at NASA Ames, has distributed diffs for ^^^^ JPL > gnu-emacs that: > > You should send mail to David, as he has been working on this > and I am sure has newer versions that what I have. Yes there are, I have sent them off to GNU but if there is a large cry for them now I can either mail or post it. > > He can be reached at: david@ames.arc.nasa.gov ^^^^^^^^^^^^^^^^^ Right agency wrong branch : david@elroy.jpl.nasa.gov -- 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!
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!
meissner@tiktok.dg.com (Michael Meissner) (05/17/89)
In article <TALE.89May12023656@imagine.pawl.rpi.edu> tale@pawl.rpi.edu writes: | 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? | | Two reasons that I can think of: | | a) debugging is hell on something link edited with shared libraries. | | b) loadup is slower (often times perceptibly, not just some sort of | unnoticeable benchmark thing) when using shared libraries. There are three other possible reasons: c) RMS and/or other people at FSF may not run SunOS 4.00 (which introduced shared libraries to the sun world); d) Shared libraries interfere with the way GNU emacs' internals; e) nobody has done the work and submitted it to the FSF. | I am pretty certain that it _can_ be compiled with the libraries (ie, | what should prevent it, code-wise), but it isn't. The primary | argument for using them is to cut down on size of the application, but | the subsequent loss of debugging power and load-up time outweighs that | consideration as long as you have the space on your system. After hacking on GNU emacs, including doing half of the port to the Data General MV series, I can state that GNU emacs' internals are probably not condusive to most people's shared libraries. In case you are curious, the way GNU is normally built is as follows: You compile the C portion of GNU. You link these together to provide temacs. Temacs is run and loads in all of the standard lisp files into it's address space. Temacs then builds an executable 'xemacs', which contains the shared text code from temacs, and initializes the data segment with the current contents of memory after doing the load. On most systems, it also moves the 'pure' array (which holds the lisp code read in) into the text segment, so that multiple emacs' will share this. The installer then renames xemacs, and installs it whereever s/he desires. The building of the xemacs phase is where most the assumptions about how the library interacts with GNU are made, and is also the hairest place in general for porting GNU emacs to a new system. There is an option when building GNU emacs not to build xemacs this way, but enabling the option means that EVERY time you start emacs, it must reload the lisp files. This takes ~5 minutes on a loaded .5 Mips machine. Depending on how shared libraries are implemented on the Sun, garbage collection (another system dependent area) may be affected as well by shared libraries. Until you fully understand what is going on in src/alloc.c and src/unexec.c, and how it might interact with shared libraries, it's probably best not to even think about shared libraries. I don't mean to be so negative about doing the port, but the GNU emacs internals are VERY tricky, and the assumptions made are not always clear. -- Michael Meissner, Data General. Uucp: ...!mcnc!rti!xyzzy!meissner If compiles were much Internet: meissner@dg-rtp.DG.COM faster, when would we Old Internet: meissner%dg-rtp.DG.COM@relay.cs.net have time for netnews?
pinkas@hobbit.intel.com (Israel Pinkas ~) (05/17/89)
I am redirecting followups to comp.unix, where this stuff belongs. In article <39999@bbn.COM> jr@bbn.com (John Robinson) writes: > 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. Our configuration is a "dataless workstation model". Swap space (anywhere from 16M to 100M) is local. The kernel, and most of the "basic" binaries distributed are local. User directories, /usr/local, etc. are NFS mounted. We run primarily on Suns and uVaxen. With this configuration in mind, my orginal statement(s) makes more sense. > >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. No diskless nodes here. We NFS mount user data and our binary distributions (ours, not the Unix ones). > >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. Due to the statelessness of NFS, the inode on the server is not held open. As a result, if workstation A is using a binary, and somebody on workstation B deletes that binary, it is gone. Workstation A starts reporting NFS Stale File Handles. (This also happens if the file is deleted on the server.) I believe (but haven't checked) that the implementations of NFS that we have are OK when another process on A tries to delte the file. How, I am not sure. What we have done is implement a methodology. Instead of removing the file, rename it. (i.e. emacs -> .emacs.orig) The delete it a week later. The point is that hopefully in that week, all NFS references to the file are gone. (We rarely have somebody logged in for a whole week. We discourage it for various reasons, including security.) > >(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. One problem I had with GNU Emacs is that on every workstation that I have ever run on, Emacs accrues a lot of CPU time. (Let's not get into an editor war about features/CPU/memory.) After a certain amount of CPU, the kernel renices the process for me. Nasty for interactive processes. After a week, even if I never touch a key, Emacs is dogmeat. (The again, so is xclock.) -Israel Pinkas -- -------------------------------------- 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
jik@athena.mit.edu (Jonathan I. Kamens) (05/17/89)
In article <39999@bbn.COM> jr@bbn.com (John Robinson) writes: >In article <PINKAS.89May14180259@hobbit.intel.com>, pinkas@hobbit >(Israel Pinkas ~) writes: >>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. Since an NFS server does not save any state (well, at least, not unless you've got the lock manager running :-), it cannot possibly know when a client is using a particular binary. Therefore, when you delete a file using NFS, the file goes away. An exception to this is if you delete a file and are running it *on the same host* when you delete it. NFS clients are smart enough to recognize this as a special case, because so many programs require a file to stay around after unlink'ing it (including many compilers, and all of the hacks discussed recently for using temporary files in shell scripts). If this happens, then the client renames the file to some wierd unique name (usually beginning with ",NFS" and ending with a number), and really tells the NFS server to remove the file once the process on the client host has closed it. This is why if an NFS client crashes you will occasionally find ",NFS" files floating around the filesystem -- the client didn't get a chance to tell the server to get rid of those files before it crashed. One of the side-effects of the amazing disappearing binaries is that sites that use NFS a lot for moving around binaries have to modify their installation procedures (read "Makefiles") so that the old version of the binary is moved out of the way rather than deleted. This way, assuming that the next installation won't happen for a while, people who are still running the old version will eventually end the process and the next time they run the program they'll get the new version. My Makefiles usually do: install: -mv $(DESTDIR)$(BINDIR)/$(TARGET) $(DESTDIR)$(BINDIR)/.\#$(TARGET) install -c -s $(TARGET) $(DESTDIR)$(BINDIR) Jonathan Kamens USnail: MIT Project Athena 410 Memorial Drive, No. 223F jik@Athena.MIT.EDU Cambridge, MA 02139-4318 Office: 617-253-4261 Home: 617-225-8218
jr@bbn.com (John Robinson) (05/18/89)
In article <6006@xyzzy.UUCP>, meissner@tiktok (Michael Meissner) writes: ...A lucid discussion of the issues of GNU emacs vs shared libraries (many thanks!)... >The building of the xemacs phase is where most the assumptions about >how the library interacts with GNU are made, and is also the hairest >place in general for porting GNU emacs to a new system. There is an >option when building GNU emacs not to build xemacs this way, but >enabling the option means that EVERY time you start emacs, it must >reload the lisp files. This takes ~5 minutes on a loaded .5 Mips >machine. > >Depending on how shared libraries are implemented on the Sun, garbage >collection (another system dependent area) may be affected as well by >shared libraries. > >Until you fully understand what is going on in src/alloc.c and >src/unexec.c, and how it might interact with shared libraries, it's >probably best not to even think about shared libraries. I don't mean >to be so negative about doing the port, but the GNU emacs internals >are VERY tricky, and the assumptions made are not always clear. It struck me that the way to build emacs is to make the compiled, loaded elisp into a shared library. Can anyone comment on the feasibliity of this? It seems to address the need that emacs' loadup phase addresses, and by definition is the "right" way to do things in SunOS 4 and other shared-library universes. Since this stuff is by definition non-portable, is a shared-library approach better than an unexec approach in jamming one less unportable feature into one executable? I realize that it may not have the speed of an unshared unexec'd emacs in many cases. I wonder if GNU's not Unix will have shared libraries... -- /jr jr@bbn.com or bbn!jr C'mon big money!
denny@mcmi.UUCP (Denny Page) (05/18/89)
jr@bbn.com (John Robinson) writes: >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? Yes, NFS breaks this behavior. Being completely stateless on the server side, it's not really optional. You can of course run an rm demon :-), or perhaps use the locking demon. Serious canal water. When they first brought up NFS, they ran into problems with this, particularly in sendmail (and csh?), if memory serves. Sendmail liked to create files, open them, and then remove them. This was fixed by hacking sendmail. -- Someday never comes
bet@dukeac.UUCP (Bennett Todd) (05/18/89)
In article <11471@bloom-beacon.MIT.EDU> jik@athena.mit.edu (Jonathan I. Kamens)
writes an excellent explanation of NFS's stateless nature, and its
implications for removing binaries of currently-running programs and suchlike.
I would add that an alternative network distributed filesystem is available
for some systems (not nearly as many as NFS) called RFS. Designed by AT&T, it
differs from NFS in several important respects. It sincerely attempts to
maintain the semantics of unlink removing the name, but not freeing the inode
and data blocks until the last open handle is closed. This makes it more true
to UNIX filesystem semantics; it also forces it to be stateful, and is reason
enough for me to hope I never have to administrate such a network. Sun's NFS
is wonderful to support, since the surprises are reasonably obscure and
infrequent, and the common case of systems going down and whatnot is handled
extremely well and robustly. We can reboot our main server anytime, and the
worst anyone sees is a minute or so of lockup. Reboot an RFS server and you
better reboot every client while you are about it. Another important feature
of RFS is support for device special files; the resulting major/minor device
numbers are correctly processed by the server, rather than being interpreted
relative to the client the way NFS does. On the other hand, by having such
complete detailed specification of UNIX filesystem semantics, efforts to
support RFS from non-UNIX OS platforms are at a great disadvantage relative to
NFS, which has OS independence as an important goal.
To sum up, I don't mean to beat up on RFS. Given a reliable LAN with reliable
homogenous servers and clients, it delivers a much higher level of
functionality, and truly distributes the UNIX filesystem transparently. On the
other hand, hetrogenous networks with unreliable servers see better service
from NFS.
Obviously, these are my opinions only; I would love to be taught why I am
wrong, if anybody would care to enlighten me. But please be nice:-).
-Bennett
bet@orion.mc.duke.edudarin@hitchhiker.laic.uucp (Darin Johnson) (05/20/89)
>>There is an >>option when building GNU emacs not to build xemacs this way, but >>enabling the option means that EVERY time you start emacs, it must >>reload the lisp files. This takes ~5 minutes on a loaded .5 Mips >>machine. > >It struck me that the way to build emacs is to make the compiled, >loaded elisp into a shared library. The VMS version just creates a dump file that is the data created while reading in the lisp files. The normal running version is the same executable that is used to build the dump file. When run normally, a dump file is specified, and that is loaded in. This won't work as well in UNIX since you would always have to have an alias (you have to have one anyway in VMS). The same method is used for VMS TeX. I compiled it with the shared C library without too many problems (but Sun shared libraries may have other problems). Using this method, the dump portion can be paged to the normal swap device, even though the text portion may not (if you have a local swap disk, but load emacs over NFS, this may make a big difference). Darin Johnson (leadsv!laic!darin@pyramid.pyramid.com) We now return you to your regularly scheduled program.
kjones@talos.UUCP (Kyle Jones) (05/24/89)
In article <40094@bbn.COM> jr@bbn.com (John Robinson) writes: > It struck me that the way to build emacs is to make the compiled, > loaded elisp into a shared library. Can anyone comment on the > feasibliity of this? It seems to address the need that emacs' loadup > phase addresses, and by definition is the "right" way to do things in > SunOS 4 and other shared-library universes. Since this stuff is by > definition non-portable, is a shared-library approach better than an > unexec approach in jamming one less unportable feature into one > executable? Shared libraries strike me as being the cleaner way, in that once shared libraries become more common, the various versions of unexe.c can be replaced by something more easily understood. If UNIX systems are in fact converging the result may be a bit more portable. As for me, the approach I favor is to rework unexec.c to dump a series of C files. These files would contain definitions for the initialization of the appropriate Lisp data structures. The files would be compiled and Emacs would be linked with these objects to produce a dumped executable. This approach has already been successfully used in at least one Lisp system, and I'm told that a C version of TeX unexecs in this way. This approach has the advantage of being completely portable, if implemented properly. It can be done, but it will require a massive reorganization of Emacs' C source to isolate all global variables and tables that are dumped. Also Emacs' memory allocation procedures will need to be decoupled from malloc()'s internals, and probably some work will be required to alert the garbage collector to thses shenanigans. Not a project for the timid. It would have been much easier when Emacs' was younger and smaller and wasn't walking the tightrope between so many systems. So massive a rewrite now would probably stir a plethora of old bugs back into life. kyle jones <kjones@talos.UUCP> ...!uunet!talos!kjones "It's bigger because it ate Rachel!" Laverne cried, and began to scream again.
matt@oddjob.uchicago.edu (Matt Crawford) (05/25/89)
After seeing a dozen of these articles, it finally occurred to me that I already have emacs running with shared libraries under 4.3 BSD on the Elxsi-6400 here. Elxsi implements shared libraries by having them installed in high memory shared among all processes, with a jump table in a known location. I didn't need to do anything to the installation procedure that I didn't have to do before Elxsi offered shared libraries. The standard GNU emacs loadup and unexec procedure is used. ________________________________________________________ Matt Crawford matt@oddjob.uchicago.edu