From: Rick DeNatale Date: 2009-12-12T12:36:49+09:00 Subject: [ruby-core:27149] Re: Ruby's GC On Fri, Dec 11, 2009 at 12:26 PM, Evan Phoenix wrote: > > On Dec 11, 2009, at 7:08 AM, Yukihiro Matsumoto wrote: > >> Hi, >> >> In message "Re: [ruby-core:27144] Re: Ruby's GC" >> � �on Fri, 11 Dec 2009 23:57:24 +0900, Rick DeNatale writes: >> >> |I suspect that the write barrier can be implemented rather efficiently >> |depending on how memory layout is done. You need to be able to >> |efficiently distinguish between mutations to references in old objects >> |(which need to be remembered) and mutations in new objects, which >> |don't. >> | >> |One interesting problem, is what effect a copying GC would have on the >> |API to C extensions, since object addresses would no longer be stable >> |over time. >> >> Non conservative GC would damage almost all C extensions for Ruby. >> I don't think it's acceptable for CRuby. > > A copy collector would also break almost all C extensions, because it's common for people to store a reference to an object somewhere "secret", and then store in somewhere normal to keep it alive. Because the current GC doesn't move objects, the "secret" reference stays valid as long as the object lives. > > With a copy collector, all references need to be fixed up, so the "secret" references would be invalidated. > > For Rubinius, we implemented an indirection layer between the C extensions and the GC that uses handles. These handles don't move, so C extensions can store "secret" references to them and GC can still move things behind the scene, so long as the handle is internally updated. Right, and that's what I was hinting at. I don't think that it's an issue of conservative vs. precise GC, the trick of storing a reference to an object with a 'secret' pointer someplace normal deals with objects being freed behind one's back. But there have been implementations for languages like Smalltalk with both a copying GC, and an api for writing extensions in C or C equivalents which provides for the extensions working despite moving objects. Also there's a difference between extensions which are merely wrappers on external function libraries, and those which are new VM primitives. The latter know that they are dealing with objects in the host language, while the former do not, any objects need to be converted to datatypes understood by the code being called so no object pointers cross the API. And when extensions which know about objects deal with them they need to deal with them through macros and functions provided by the implementation. Even with MRI, C code can't simply treat an object reference as a pointer, it needs to use the macros and rb_functions to convert the VALUE type to something which the extension code can deal with. So I suspect that it might be possible to maintain the existing MRI extension interface at the source level in the face of a copying collector, but the extensions would need to be recompiled and would not be binary compatible. But we have that level of incompatibility at least between Ruby 1.8.x and Ruby 1.9.x extensions. So I don't think it should be an impediment to having a copying GC, with it's benefits, in a future Ruby implementation. Even better if the api for primitives could be made (more) implementation independent sort of like an FFI for primitives rather than library wrappers. -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Twitter: http://twitter.com/RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale