9 ms·

Don't know if it's true, but it makes a fun story: ST80 used reference counting with counts saturating at some low number (like 127), and of course there are pr

by kabdib 4y ago

Don't know if it's true, but it makes a fun story: ST80 used reference counting with counts saturating at some low number (like 127), and of course there are problems collecting circular references. A comprehensive analysis of a modern image, with Xerox PARC lineage, discovered garbage that had been uncollected for 20-30 years.

Rochus 4y ago
It is true, that there is uncollected garbage in the original Xerox ST80 image. I've built some tools to analyze the image and also a VM which can be interrupted at any time to analyze the current state of the image (see https://github.com/rochus-keller/Smalltalk https://github.com/rochus-keller/Smalltalk). There are two zombie processes (OID 6662 and 19ba). There are also a couple of BlockContext and MethodContext which have a nil sender and a reference to an unknown method, but which are still referenced from somewhere (i.e. the collection is prevented, even with mark & sweep). E.g. OID 79a2 of class BinaryChoice. I have a full list if anybody is interested.
- floren 4y ago
  It's things like this that always made me look a bit askance at Smalltalk. It feels a little like "Document_Final_FINAL_v3_(2).docx", a little like a dirty old whiteboard where you can still see outlines of notes from last year. Might not be a fair assessment, but as an outsider I've always felt this way about image-based systems.
  - Rochus 4y ago
    Deploying an application was always an adventure. You could never be completely sure that it didn't contain things it shouldn't.
    - igouy 4y ago
      For some meaning of "contain things it shouldn't": Given that the base image we started working with didn't "contain things it shouldn't" why could we not be completely sure that base image + source code fileIn didn't "contain things it shouldn't" ?
      - Rochus 4y ago
        First, as most other companies using ST we were not working on the original image, but on a company-specific one that had been in use for a long time and contained a lot of company-specific stuff. On the other hand, there were also things in the original images of the commercial STs that one would or should not ship with the product.
        pjmlp 4y ago
        Which is why image trimming tools did exist.
        Rochus 4y ago
        I had Envy in later projects, which was very useful, but you simply had to trust it, which is not the same as to be completely sure.
        igouy 4y ago
        Rather than simply trust, wouldn't we test? (At some point, we might question whether we're putting similar effort into testing other software tools.)
        Rochus 4y ago
        We tested until our ears fell off; in particular, we had also to test all the stuff that the compiler (or linker) would otherwise have told us in a statically typed language; there was no other way; might explain why I directly switched to Ada for some time after ST; but how do you test for dead code (i.e. things in the image not used but still there for some reason)? It is not for nothing that people speak of a "Big ball of Mud" in the context of image based languages.
        igouy 4y ago
        > We tested until our ears fell off… And did you discover stuff that was reported to have been removed but your tests showed was not removed? In other words, examples where "trust it" would be a demonstrable mistake. > It is not for nothing that people speak of a "Big ball of Mud" in the context of image based languages. What process was used to manage source code? "At the outset of a project involving two or more programmers: Do assign a member of the team to be the version manager. … The responsibilities of the version manager consist of collecting and cataloging code files submitted by all members of the team, periodically building a new system image incorporating all submitted code files, and releasing the image for use by the team. The version manager stores the current release and all code files for that release in a central place, allowing team members read access, and disallowing write access for anyone except the version manager." (page 500) 1984 "Smalltalk-80 The Interactive Programming Environment" https://rmod-files.lille.inria.fr/FreeBooks/TheInteractiveProgrammingEnv/TheInteractiveProgrammingEnv.pdf https://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePr...
    - igouy 4y ago
      ( cont. from https://news.ycombinator.com/item?id=31999774 https://news.ycombinator.com/item?id=31999774 ) > … no algorithm that can identify all dead code reliably… Why were you so concerned with the removal of all dead code? Compared to "… nobody had the source code…" it seems like a minor issue.
      - igouy 4y ago
        ( cont. ) imo the more usual concern would be mistakenly removing code that was not dead. Without a design document, we might think there would be no senders of #factorial without understanding that the intention was to invoke that method on the command line. For example, $ cat fact.st Stdio stdout nextPutAll: 100 factorial printString; nextPut: Character lf.! SmalltalkImage current snapshot: false andQuit: true! $ bin/pharo --headless Pharo10-SNAPSHOT-64bit-502addc.image fact.st 93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000 So instrumenting methods and logging — https://stackoverflow.com/a/162719 https://stackoverflow.com/a/162719
- igouy 4y ago
  Is there uncollected garbage in the Smalltalk Squeak 6.0 image?
  - Rochus 4y ago
    I have no information about this. Squeak uses a different image format, incompatible with my tools.
erik_seaberg 4y ago
I’m reminded of junk DNA.
- isaacimagine 4y ago
  I mean, Kay was a biologist :)
  - andsoitis 4y ago
    Haha. Alan Kay wrote: "At Utah sometime after Nov 66 when, influenced by Sketchpad, Simula, the design for the ARPAnet, the Burroughs B5000, and my background in Biology and Mathematics, I thought of an architecture for programming. It was probably in 1967 when someone asked me what I was doing, and I said: "It's object-oriented programming". The original conception of it had the following parts. - I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages (so messaging came at the very beginning -- it took a while to see how to do messaging in a programming language efficiently enough to be useful)." http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay...
    - Rochus 4y ago
      It's interesting to note that he explicitly mentions "November 1966" and also refers to Simula. The ACM paper about Simula I appeared in September 1966 (see https://dl.acm.org/doi/10.1145/365813.365819 https://dl.acm.org/doi/10.1145/365813.365819), so he might have read it. Simula (or Simula I as it is called today) was a language to support discrete event simulation and had active objects (called "processes") for that purpose which "sent events" to each other (i.e. the process is activated at the event time). The language was already presented in 1962 at the second international conference on information processing held in Munich. The actually "object-oriented" Simula version with classes, inheritance and virtual methods appeared in 1967. Kay's vision applies to Smalltalk-72 to some degree, but Smalltalk-76 then also switched to inheritance and compiled virtual methods.

by kabdib 4y ago

Rochus 4y ago

It is true, that there is uncollected garbage in the original Xerox ST80 image. I've built some tools to analyze the image and also a VM which can be interrupted at any time to analyze the current state of the image (see https://github.com/rochus-keller/Smalltalk https://github.com/rochus-keller/Smalltalk). There are two zombie processes (OID 6662 and 19ba). There are also a couple of BlockContext and MethodContext which have a nil sender and a reference to an unknown method, but which are still referenced from somewhere (i.e. the collection is prevented, even with mark & sweep). E.g. OID 79a2 of class BinaryChoice. I have a full list if anybody is interested.

floren 4y ago
It's things like this that always made me look a bit askance at Smalltalk. It feels a little like "Document_Final_FINAL_v3_(2).docx", a little like a dirty old whiteboard where you can still see outlines of notes from last year. Might not be a fair assessment, but as an outsider I've always felt this way about image-based systems.
- Rochus 4y ago
  Deploying an application was always an adventure. You could never be completely sure that it didn't contain things it shouldn't.
  - igouy 4y ago
    For some meaning of "contain things it shouldn't": Given that the base image we started working with didn't "contain things it shouldn't" why could we not be completely sure that base image + source code fileIn didn't "contain things it shouldn't" ?
    - Rochus 4y ago
      First, as most other companies using ST we were not working on the original image, but on a company-specific one that had been in use for a long time and contained a lot of company-specific stuff. On the other hand, there were also things in the original images of the commercial STs that one would or should not ship with the product.
      - pjmlp 4y ago
        Which is why image trimming tools did exist.
        Rochus 4y ago
        I had Envy in later projects, which was very useful, but you simply had to trust it, which is not the same as to be completely sure.
        igouy 4y ago
        Rather than simply trust, wouldn't we test? (At some point, we might question whether we're putting similar effort into testing other software tools.)
        Rochus 4y ago
        We tested until our ears fell off; in particular, we had also to test all the stuff that the compiler (or linker) would otherwise have told us in a statically typed language; there was no other way; might explain why I directly switched to Ada for some time after ST; but how do you test for dead code (i.e. things in the image not used but still there for some reason)? It is not for nothing that people speak of a "Big ball of Mud" in the context of image based languages.
        igouy 4y ago
        > We tested until our ears fell off… And did you discover stuff that was reported to have been removed but your tests showed was not removed? In other words, examples where "trust it" would be a demonstrable mistake. > It is not for nothing that people speak of a "Big ball of Mud" in the context of image based languages. What process was used to manage source code? "At the outset of a project involving two or more programmers: Do assign a member of the team to be the version manager. … The responsibilities of the version manager consist of collecting and cataloging code files submitted by all members of the team, periodically building a new system image incorporating all submitted code files, and releasing the image for use by the team. The version manager stores the current release and all code files for that release in a central place, allowing team members read access, and disallowing write access for anyone except the version manager." (page 500) 1984 "Smalltalk-80 The Interactive Programming Environment" https://rmod-files.lille.inria.fr/FreeBooks/TheInteractiveProgrammingEnv/TheInteractiveProgrammingEnv.pdf https://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePr...
  - igouy 4y ago
    ( cont. from https://news.ycombinator.com/item?id=31999774 https://news.ycombinator.com/item?id=31999774 ) > … no algorithm that can identify all dead code reliably… Why were you so concerned with the removal of all dead code? Compared to "… nobody had the source code…" it seems like a minor issue.
    - igouy 4y ago
      ( cont. ) imo the more usual concern would be mistakenly removing code that was not dead. Without a design document, we might think there would be no senders of #factorial without understanding that the intention was to invoke that method on the command line. For example, $ cat fact.st Stdio stdout nextPutAll: 100 factorial printString; nextPut: Character lf.! SmalltalkImage current snapshot: false andQuit: true! $ bin/pharo --headless Pharo10-SNAPSHOT-64bit-502addc.image fact.st 93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000 So instrumenting methods and logging — https://stackoverflow.com/a/162719 https://stackoverflow.com/a/162719
igouy 4y ago
Is there uncollected garbage in the Smalltalk Squeak 6.0 image?
- Rochus 4y ago
  I have no information about this. Squeak uses a different image format, incompatible with my tools.

erik_seaberg 4y ago

I’m reminded of junk DNA.

isaacimagine 4y ago
I mean, Kay was a biologist :)
- andsoitis 4y ago
  Haha. Alan Kay wrote: "At Utah sometime after Nov 66 when, influenced by Sketchpad, Simula, the design for the ARPAnet, the Burroughs B5000, and my background in Biology and Mathematics, I thought of an architecture for programming. It was probably in 1967 when someone asked me what I was doing, and I said: "It's object-oriented programming". The original conception of it had the following parts. - I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages (so messaging came at the very beginning -- it took a while to see how to do messaging in a programming language efficiently enough to be useful)." http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay...
  - Rochus 4y ago
    It's interesting to note that he explicitly mentions "November 1966" and also refers to Simula. The ACM paper about Simula I appeared in September 1966 (see https://dl.acm.org/doi/10.1145/365813.365819 https://dl.acm.org/doi/10.1145/365813.365819), so he might have read it. Simula (or Simula I as it is called today) was a language to support discrete event simulation and had active objects (called "processes") for that purpose which "sent events" to each other (i.e. the process is activated at the event time). The language was already presented in 1962 at the second international conference on information processing held in Munich. The actually "object-oriented" Simula version with classes, inheritance and virtual methods appeared in 1967. Kay's vision applies to Smalltalk-72 to some degree, but Smalltalk-76 then also switched to inheritance and compiled virtual methods.