On 11/10/2013 1:48 PM, Jonathan S. Shapiro wrote:
*Opportunistic Relocation* * *One attraction to (most) RC schemes is that objects don't get relocated. This makes it /much/ easier to interact successfully with libraries written in C/C++. So much so that some amount of performance can and should be sacrificed in the interest of interoperability.
Another paper I haven't worked through yet, but that looks interesting on this point:
http://www.pllab.riec.tohoku.ac.jp/papers/icfp2011UenoOhoriOtomoAuthorVersion.pdfThis is ongoing work on SML#, which seeks seamless integration with C-like languages, and supports full natural representation of native machine types. This paper provides a non-moving generational collector that addresses mark-sweep fragmentation and still supports average constant time bump-pointer type allocation (worst-case logK(segmentSize), where K = pointer size in bits).
The SML# approach to object headers to identify pointers might be useful to BitC too.
Sandro
A key reason the immix work succeeds is that it does opportunistic relocation, which would appear (at first glance, anyway) to defeat interoperability with C/C++. The immix approach, however, degrades gracefully in the presence of pinned objects. As long as the pins happen properly, C and C++ code can reference objects in the GC heap.An interesting question here becomes: could we hybridize C to sandbox "unsafe" references and introduce a new class of "memory safe" references? Things like this have been tried before, obviously.*Summary* * *I'm inclined, at this point, to adopt something like RC-immix as the baseline for storage management in BitC. The one piece that I don't (yet) feel I have a handle on is whether modern RC methods degrade, and if so how badly, on weakly ordered memory subsystems.shap _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
