4 ms·

WasmGC does not support interior pointers so Go cannot benefit from this, at least not without something ugly like fat pointers.

• aatd86 3y ago
  How does it not support interior pointers? Can you explain some more? Seemed to me that it did? Example given in the link. https://gist.github.com/kripken/5cd3e18b6de41c559d590e44252eafff https://gist.github.com/kripken/5cd3e18b6de41c559d590e44252e... Or is it that the GC ignores interior pointers during mark and sweep? Then once Java introduces value types, wouldn't the language encounter the same problem for composite types? Would be a weird choice to not handle interior pointers. I'm a bit out-of-my-depth here, just wondering.
  • skybrian 3y ago
    That’s not an example of interior pointers as used in Go. In Go you can have a fixed-size array of structs, where each struct contains many fields, including a fixed-size array field. The whole thing can be allocated at once and is automatically zeroed out. And then you can take a pointer to any struct’s field or any internal array element. “Interior” means the interior of a single object. A pointer to anywhere within an object prevents it from being collected.
    • kaba0 3y ago
      Can’t it be compiled as a struct of a normal pointer and an “index” to a field/offset whatever? Not the most efficient, but with value types it might not be too bad.
      • skybrian 3y ago
        Probably, but it means all pointers need that representation because any pointer could be an interior pointer. If you’re given an arbitrary pointer, it could point somewhere within any object. (Unless it can be proven otherwise using escape analysis.) Whether a pointer is an interior pointer or not isn’t part of its type in Go.
      • jlokier 3y ago
        That's what 4ad meant by "something ugly like fat pointers". The overhead compared with interior pointers is relatively high due to the extra space for the fat pointer index, which space is taken everywhere a pointer could be an interior pointer, even if it's rare. When a language runtime can optimise in whatever way it needs to, if interior pointers aren't an option there are various schemes to avoid the fat pointer space overhead and replace it with time overhead, but they often involve using unused bits in the pointer word, or recognise certain address ranges. Unfortunately, I assume those techniques are incompatible with a GC like WasmGC's, which requires all pointers to use the standard pointer representation, so prevents these kinds of space and time optimisations.
    • kevincox 3y ago
      It seems that you can work around this by allocating every field separately. This is obviously going to perform worse but I don't think it would actually violate the language behaviour (other than maybe assumptions using unsafe memory access). Combined with some whole-program analysis to see which fields ever have their address taken this could even be a relatively small performance hit. (Although I think this whole-program analysis would fail in the face of reflection.) Depending on how much code you want to run it may be interesting to be able to decide between shipping a GC implementation and slowing down your code to avoid it. If it is an extra 50% code size on top of a fairly small amount of first-party code you may pick WasmGC.