7 ms·

This sounds terrible

forkerenok 2y ago
If you squint hard enough, this is an implementation of a higher order garbage collection: MarkNothingAndSweepEverything. There, formalized the approach, so you can't call it terrible anymore.
- crabbone 2y ago
  Oh no it isn't. Garbage collector needs to prove that what's being collected is garbage. If objects get collected because of an error... that's not really how you want GC to work. If you are looking for an apt metaphor, Stalin sort might be more in line with what's going on here. Or maybe "ostrich algorithm".
  - zoky 2y ago
    I think it’s more like Tech Support Sort, as in “Try turning it off and on again and see if it’s sorted”.
    - mech422 2y ago
      LOL - I like that one! :-)
  - nukethegrbj 2y ago
    >Garbage collector needs to prove that what's being collected is garbage Some collectors may need to do this, but there are several collectors that don't. EpsilonGC is a prime example of a GC that doesen't need to prove anything
    - crabbone 2y ago
      EpsilonGC is a GC in the same sense as a suitable-size stick is a fully automatic rifle when you hold it to your shoulder and say pew-pew... I mean, I interpret your comment to be a joke, but you could've made it a bit more obvious for people not familiar with the latest fancy in Java world.
deleted 2y ago
[deleted]
rakoo 2y ago
To be fair this is what the BEAM vm structures everything on: If something is wonky, crash it and restart from a known ok state. Except when BEAM does it everyone says it's brilliant
- ElevenLathe 2y ago
  It's one thing to design a crash-only system, and a quite different to design a system that crashes all the time but paper over it with a cloud orchestration layer later.
  - rakoo 2y ago
    I don't see the fundamental difference. Both systems work under expected conditions and will crash parts of it if the conditions don't happen. The scales (and thus the visibility of bugs) change, the technologies change, but the architecture really doesn't. Erlang programs are not magically devoid of bugs, the bugs are just not creating errors
    - ElevenLathe 2y ago
      I understand this perspective but a BEAM thread can die and respawn in microseconds but this solution involves booting a whole Linux kernel. The cost of the crash domain matters. Similarly, thread-per-request webservers are a somewhat reasonable architecture on unix but awful on Windows. Why? Windows processes are more expensive to spawn and destroy than unix ones.

If you squint hard enough, this is an implementation of a higher order garbage collection: MarkNothingAndSweepEverything. There, formalized the approach, so you can't call it terrible anymore.

crabbone 2y ago
Oh no it isn't. Garbage collector needs to prove that what's being collected is garbage. If objects get collected because of an error... that's not really how you want GC to work. If you are looking for an apt metaphor, Stalin sort might be more in line with what's going on here. Or maybe "ostrich algorithm".
- zoky 2y ago
  I think it’s more like Tech Support Sort, as in “Try turning it off and on again and see if it’s sorted”.
  - mech422 2y ago
    LOL - I like that one! :-)
- nukethegrbj 2y ago
  >Garbage collector needs to prove that what's being collected is garbage Some collectors may need to do this, but there are several collectors that don't. EpsilonGC is a prime example of a GC that doesen't need to prove anything
  - crabbone 2y ago
    EpsilonGC is a GC in the same sense as a suitable-size stick is a fully automatic rifle when you hold it to your shoulder and say pew-pew... I mean, I interpret your comment to be a joke, but you could've made it a bit more obvious for people not familiar with the latest fancy in Java world.

deleted 2y ago

[deleted]

rakoo 2y ago

To be fair this is what the BEAM vm structures everything on: If something is wonky, crash it and restart from a known ok state. Except when BEAM does it everyone says it's brilliant

ElevenLathe 2y ago
It's one thing to design a crash-only system, and a quite different to design a system that crashes all the time but paper over it with a cloud orchestration layer later.
- rakoo 2y ago
  I don't see the fundamental difference. Both systems work under expected conditions and will crash parts of it if the conditions don't happen. The scales (and thus the visibility of bugs) change, the technologies change, but the architecture really doesn't. Erlang programs are not magically devoid of bugs, the bugs are just not creating errors
  - ElevenLathe 2y ago
    I understand this perspective but a BEAM thread can die and respawn in microseconds but this solution involves booting a whole Linux kernel. The cost of the crash domain matters. Similarly, thread-per-request webservers are a somewhat reasonable architecture on unix but awful on Windows. Why? Windows processes are more expensive to spawn and destroy than unix ones.