4 ms·

GC is but one component of the massive operating system that is current web browsers. This is classic anti-Rust "argument" which states that code with tiny isla

GC is but one component of the massive operating system that is current web browsers. This is classic anti-Rust "argument" which states that code with tiny islands of well tested and thoroughly reviewed unsafe functions is somehow equal to 100% unsafe C++.

pizlonator 2y ago
It’s not an island. The whole rest of the browser has to interact with the GC the right way (barriers, pointer tracking) or else you escape memory safety
- Dylan16807 2y ago
  A ton of things using the GC code fits fine with what they meant by "island". You shouldn't need unsafe code all over, just normal ownership tracking that calls into the GC. And while I wouldn't normally call a GC "tiny", browsers are pretty enormous.
  - pizlonator 2y ago
    That's not what happens in the browser at all. The JS engine - about 1/3 of the browser engine, ish - is tightly coupled to the GC through-and-through. Let's even assume you have a JS engine that doesn't JIT. (If it did JIT then rewriting it in a memory safe language isn't going to do much for you at all.) The interpreter, the runtime, and the libraries are going to have to be making decisions on behalf of the GC (for stuff like weak maps, at least) and is going to have to play along with the GC's tracing (every class in the JS engine participates in the JS GC and so must tell the GC how to mark - or worse, move - outgoing references). The rest of the browser has to play along as well, just not as much. The DOM is basically JS's "standard library" within the browser and it also needs to have its objects play along with the GC's semantics. So, maybe there is code out there where the GC can be an island. The browser is not that.
    - Dylan16807 2y ago
      Tight coupling is not a problem. Ignore the word "island" if that's your issue. Pretend it talked about sealing each unsafe system behind a safe API. And yes, you can make that happen. Marking references for a GC is in the same ballpark as a custom allocator. It doesn't have to fill the code using it with unsafe.
      - pizlonator 2y ago
        There’s no way to seal the GC’s unsafety behind a safe API unless the safe code pins every GC object it touches. That’s not what happens in a browser engine - the GC has to ask the rest of the engine where its pointers are, and if any part of the browser fails to account for a pointer correctly, then you get use after free as soon as the GC runs. It’s a harder problem than you make it seem.
        Dylan16807 2y ago
        Doesn't Rc already demonstrate that kind of accounting? You're going to have to add GC awareness to objects so it can trace through them, but the code that makes and manipulates those objects can have all the necessary rules enforced by types.
        pizlonator 2y ago
        It’s possible with RC but not GC. GC != RC. A type system can let you say things like “make sure someone finds out when I assign this pointer”. But that’s not what GC wants, unless (as I said before) you’re happy with your non-GC heap pinning objects (the browser isn’t, but some GC clients are, sometimes). GC wants a guarantee like: you cannot have a pointer in any data structure unless that data structure can be found by GC, and when it is found, make sure to respond to the GC’s request to scan it. That ends up being hard to do with any type system, unless that type system only allows objects to be allocated by that GC and the abstraction sits in the compiler/runtime below the type system (like in Java, Go, and Fil-C).

pizlonator 2y ago

It’s not an island. The whole rest of the browser has to interact with the GC the right way (barriers, pointer tracking) or else you escape memory safety

Dylan16807 2y ago
A ton of things using the GC code fits fine with what they meant by "island". You shouldn't need unsafe code all over, just normal ownership tracking that calls into the GC. And while I wouldn't normally call a GC "tiny", browsers are pretty enormous.
- pizlonator 2y ago
  That's not what happens in the browser at all. The JS engine - about 1/3 of the browser engine, ish - is tightly coupled to the GC through-and-through. Let's even assume you have a JS engine that doesn't JIT. (If it did JIT then rewriting it in a memory safe language isn't going to do much for you at all.) The interpreter, the runtime, and the libraries are going to have to be making decisions on behalf of the GC (for stuff like weak maps, at least) and is going to have to play along with the GC's tracing (every class in the JS engine participates in the JS GC and so must tell the GC how to mark - or worse, move - outgoing references). The rest of the browser has to play along as well, just not as much. The DOM is basically JS's "standard library" within the browser and it also needs to have its objects play along with the GC's semantics. So, maybe there is code out there where the GC can be an island. The browser is not that.
  - Dylan16807 2y ago
    Tight coupling is not a problem. Ignore the word "island" if that's your issue. Pretend it talked about sealing each unsafe system behind a safe API. And yes, you can make that happen. Marking references for a GC is in the same ballpark as a custom allocator. It doesn't have to fill the code using it with unsafe.
    - pizlonator 2y ago
      There’s no way to seal the GC’s unsafety behind a safe API unless the safe code pins every GC object it touches. That’s not what happens in a browser engine - the GC has to ask the rest of the engine where its pointers are, and if any part of the browser fails to account for a pointer correctly, then you get use after free as soon as the GC runs. It’s a harder problem than you make it seem.
      - Dylan16807 2y ago
        Doesn't Rc already demonstrate that kind of accounting? You're going to have to add GC awareness to objects so it can trace through them, but the code that makes and manipulates those objects can have all the necessary rules enforced by types.
        pizlonator 2y ago
        It’s possible with RC but not GC. GC != RC. A type system can let you say things like “make sure someone finds out when I assign this pointer”. But that’s not what GC wants, unless (as I said before) you’re happy with your non-GC heap pinning objects (the browser isn’t, but some GC clients are, sometimes). GC wants a guarantee like: you cannot have a pointer in any data structure unless that data structure can be found by GC, and when it is found, make sure to respond to the GC’s request to scan it. That ends up being hard to do with any type system, unless that type system only allows objects to be allocated by that GC and the abstraction sits in the compiler/runtime below the type system (like in Java, Go, and Fil-C).