5 ms·

I agree that dumping an image is not a great idea in the modern world, but the concept(1) dates right back to when emacs was still based on TECO on the PDP-10:

by pm215 10y ago

I agree that dumping an image is not a great idea in the modern world, but the concept(1) dates right back to when emacs was still based on TECO on the PDP-10: http://pdp-10.trailing-edge.com/mit_emacs_170_teco_1220/01/info/mkdump.info.html http://pdp-10.trailing-edge.com/mit_emacs_170_teco_1220/01/i... (and I suspect the available CPU horsepower back then was such that you pretty much needed to do tricks like this to get quick startup even if you were careful about how much lisp code you ran at startup). (1) as a part of emacs, that is -- I'd guess that "language runtime takes an image of its pre-initialized state and then just loads that" was used in non-emacs contexts before that.

lispm 10y ago
The first Lisp from the early 60s did already dump images.
- int_19h 10y ago
  Did it dump Lisp images, or the image of the entire process (including all the non-Lisp stuff)? It appears that all the complexity and instability here comes from the latter part. Lisp itself was always designed around this image dumping concept. But C and its standard library were not.
  - qwertyuiop924 10y ago
    Actually, many early unixes included undump, which let you build an executable from a coredump.
    - int_19h 10y ago
      And what were the stability guarantees for such things? Could you expect to take such a dump, bring it to a different system (potentially with different hardware, different minor OS revision etc), and expect it to work?
      - jrochkind1 10y ago
        In those days, you could pretty much never take any software to different hardware, and even different minor OS revision was asking for trouble. What you are asking for isn't something anyone expected back then. Different hardware was _really_ different.
        int_19h 10y ago
        Right, that's kinda what I was expecting. But that also explains why it was a mistake to adopt this model for Emacs, or at least to stick with it for so long (to clarify, I specifically mean full process dumps, not Lisp world dumps) - it's a different world, and it has been different for a very long time, with software and OS/hardware significantly more decoupled.
        sedachv 10y ago
        > it's a different world, and it has been different for a very long time, with software and OS/hardware significantly more decoupled. This argument makes about as much sense for core files as it does for binary executables, which is to say, not very much.
        int_19h 10y ago
        Why? A binary executable does not rely on the very fine details of the implementation of the OS heap manager, for example, while a dump necessarily would.
        sedachv 10y ago
        > A binary executable does not rely on the very fine details of the implementation of the OS heap manager, for example, while a dump necessarily would. What are you talking about? What is it about brk(2)/sbrk(2)/mmap(2) that would be a problem?
        10y ago
  - sedachv 10y ago
    This is Lisp on the IBM 704/7090 and PDP-1 in 1960-1964. Ritchie would not start work on C until 1969 and there was no standard C library (which, btw, is completely irrelevant to the runtime state of a process) for decades. There were no processes or virtual memory (the 7090 didn't even have overlays) or non-Lisp stuff other than the punch card/paper tape loader.

by pm215 10y ago

lispm 10y ago

The first Lisp from the early 60s did already dump images.

int_19h 10y ago
Did it dump Lisp images, or the image of the entire process (including all the non-Lisp stuff)? It appears that all the complexity and instability here comes from the latter part. Lisp itself was always designed around this image dumping concept. But C and its standard library were not.
- qwertyuiop924 10y ago
  Actually, many early unixes included undump, which let you build an executable from a coredump.
  - int_19h 10y ago
    And what were the stability guarantees for such things? Could you expect to take such a dump, bring it to a different system (potentially with different hardware, different minor OS revision etc), and expect it to work?
    - jrochkind1 10y ago
      In those days, you could pretty much never take any software to different hardware, and even different minor OS revision was asking for trouble. What you are asking for isn't something anyone expected back then. Different hardware was _really_ different.
      - int_19h 10y ago
        Right, that's kinda what I was expecting. But that also explains why it was a mistake to adopt this model for Emacs, or at least to stick with it for so long (to clarify, I specifically mean full process dumps, not Lisp world dumps) - it's a different world, and it has been different for a very long time, with software and OS/hardware significantly more decoupled.
        sedachv 10y ago
        > it's a different world, and it has been different for a very long time, with software and OS/hardware significantly more decoupled. This argument makes about as much sense for core files as it does for binary executables, which is to say, not very much.
        int_19h 10y ago
        Why? A binary executable does not rely on the very fine details of the implementation of the OS heap manager, for example, while a dump necessarily would.
        sedachv 10y ago
        > A binary executable does not rely on the very fine details of the implementation of the OS heap manager, for example, while a dump necessarily would. What are you talking about? What is it about brk(2)/sbrk(2)/mmap(2) that would be a problem?
        10y ago
- sedachv 10y ago
  This is Lisp on the IBM 704/7090 and PDP-1 in 1960-1964. Ritchie would not start work on C until 1969 and there was no standard C library (which, btw, is completely irrelevant to the runtime state of a process) for decades. There were no processes or virtual memory (the 7090 didn't even have overlays) or non-Lisp stuff other than the punch card/paper tape loader.