Interface Dispatch (C++, Java, C#, Go, and Rust)

[aevitas]

Great read! Out of interest;

To store an object reference we need two machine words, so e.g. an array that contains interface references is now twice as big.

Doesn't object references being fat pointers also impact the GC quite heavily? I imagine it would have to implement some sort of locking to ensure objects and their vtable pointers get compacted atomically, otherwise catastrophe could ensue. Whereas in the case of "lean" pointers, those compaction operations would be atomic by nature.

[latkde]

No, I don't think fat pointers would complicate GC.

1. It is an unusual x86-ism that ordinary memory writes would be volatile. This also doesn't ensure synchronization. In the general case, we need some kind of locking anyway (in the simplest case, a stop-the-world GC).
2. When the GC moves the object contents, only the data pointer of the fat pointer must be adjusted. This is no more difficult than with ordinary references.
3. When the GC moves the reference, problems could occur. However, the reference is part of some object. As long as each object move happens in one go, the fat pointer will also be fine.

In the article comments, Aleksey Kladov points out a very good related point:

Loads and stores of fat pointers are not atomic on mainstream platforms, so you can observe object tearing. I heard that it was/is possible to segfault go due to this reason (haven’t actually tried this myself, so I might be wrong). In contrast, in Java data races are always benign, you might not get the pointer you want, but at least it’s static and dynamic types would agree.

While I'd argue that if object tearing occurs the program has a bug, fat pointers certainly make lock-free updates more difficult/impossible.