5 ms·

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

by lispm 10y ago

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?
        int_19h 10y ago
        Correct me if I'm wrong, but if you make a process dump of the entire process, that dump would include internal structures used to maintain its heap, no? If those structures change between OS versions, for example, then the process dump from an older version would represent corrupted heap when loaded on a newer version.
        sedachv 10y ago
        None of the kernel data structures are saved or even visible to the process - the kernel memory (on Linux x64 everything mapped in the upper 128TiB) is not readable by the process. You can have a problem if the kernel system call interface changes, but that is a problem for every executable. You would need to re-compile everything on the system.
        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.

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

by lispm 10y ago

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

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?
        int_19h 10y ago
        Correct me if I'm wrong, but if you make a process dump of the entire process, that dump would include internal structures used to maintain its heap, no? If those structures change between OS versions, for example, then the process dump from an older version would represent corrupted heap when loaded on a newer version.
        sedachv 10y ago
        None of the kernel data structures are saved or even visible to the process - the kernel memory (on Linux x64 everything mapped in the upper 128TiB) is not readable by the process. You can have a problem if the kernel system call interface changes, but that is a problem for every executable. You would need to re-compile everything on the system.
        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.