Hacker News Reader

Comment by Throwawayaerlei | Hacker News Reader

One thing that hit me on reading the January 20th, 2020 blog description of MIR https://developers.redhat.com/blog/2020/01/20/mir-a-lightwei... is that it doesn't generate position independent code. Wouldn't that need to be changed for a copying GC like Ravenbrook's?

View on HN

I think it's pretty rare for copying GC to be extended to the JIT'd machine code. That is, it only makes a difference if you're moving around the machine code in memory, not if you're moving around data. (The vtables can still be moved around.. all of the function pointers in them are absolute.)

Does Ravenbook also use copying for machine code?

There is the caveat that generated machine code can embed addresses of objects that get relocated by the GC. In this case the code needs to be patched even though the code itself doesn't move.

I'm not familiar with Ravenbook. How does it handle GC roots outside the managed heap? I presume it updates the GC roots as it moves the objects they point to, or does it not support GC roots outside the managed heap? If the code refers to managed objects, you need to mark those locations in the machine code as containing GC roots, otherwise, you might GC the referenced objects, which is just as bad as moving them.

I don't really know that particular GC, but not necessarily. Code objects are usually stored in a separate area and might be managed differently than regular objects. So a copying GC might not relocate code - maybe not even collect it. In case objects are relocated by the GC, there is usually "relocation information" which can be used to patch the code after it got relocated.

MPS has different collectors, and I don't think that the generated code should be subject to a collector or include addresses to collectable objects. MPS is an very interesting library I recently started to familiarize myself with; I think it should be considered by programming languages currently using Boehm GC.

Reply on news.ycombinator.com