4 ms·
Immix is a copying collector. It's late and I may be misreading, but glancing at the code I don't see any precise object layout info for the heap in D's GC. Tha
by pcwalton 9y ago
Immix is a copying collector. It's late and I may be misreading, but glancing at the code I don't see any precise object layout info for the heap in D's GC. That is, D seems conservative for both stack and heap. How can you make Immix work with this kind of conservative GC?
- YorickPeterse 9y agoOne simple "solution" is to not implement evacuation, thereby not moving objects. In my opinion this somewhat defeats the purpose of using Immix, but some projects decided to take this route (e.g. Rubinius has/had an Immix GC but never implemented evacuation if I'm not mistaken).
- chrisseaton 9y agoPresumably adding precise stack maps and object maps would be the first step of adding IMMIX. I mean it's the compiler that chooses where to place things in the heap and the stack, so it already knows where they are.
- readittwice 9y agoSince, I don't know D, I am curious whether D-code is written in such a way that objects are assumed to be non-moving, especially when interfacing with C.
- chrisseaton 9y agoAh, yes maybe FFI and also perhaps inner pointers.
- biotronic 9y agoThe spec says the GC may move, though the current GC doesn't do that: https://dlang.org/spec/garbage.html#obj_pinning_and_gc https://dlang.org/spec/garbage.html#obj_pinning_and_gc There's also been some work on a precise GC for D: https://forum.dlang.org/post/hdwwkzqswwtffjehenjt@forum.dlang.org https://forum.dlang.org/post/hdwwkzqswwtffjehenjt@forum.dlan...
- nicwilson 9y ago> written in such a way that objects are assumed to be non-moving Not generally, but you can take the address of anything and shove it into a union or pass it off to C code that stores it somewhere. Because you can, it would be very dangerous to move objects around because of that.