This is something that can be readily solved. Dylan has no issues in this area when using the MPS (http://www.ravenbrook.com/project/mps/ http://www.ravenbrook.

This is something that can be readily solved. Dylan has no issues in this area when using the MPS (http://www.ravenbrook.com/project/mps/ http://www.ravenbrook.com/project/mps/) GC. There are a few things that are worth taking note of though ... One is that things that use addresses in memory need to be able to deal with those addresses changing. An example of this are common implementations of hash tables (due to hashing using the address). MPS provides location dependencies (http://www.ravenbrook.com/project/mps/master/manual/html/topic/location.html http://www.ravenbrook.com/project/mps/master/manual/html/top...) to deal with this. Another is that when you call into C / foreign code, you want to be able to pin your object down so that it won't move. This is commonly an issue with byte vectors / strings. For that, the language / libraries / compiler should support pinning and unpinning objects. The way that Dylan does this in the native code generator is that it makes sure there's a stack reference to the object which is enough for the GC to not move it. This is only good for short-lived things though as you don't want to disrupt GC for too long. Another thing to take note of is that you sometimes want to store an object reference in native code and out of reach of the GC. A common situation where this happens is storing user data or callbacks. In this situation, we can register a Dylan object to have a handle which we can pass to native code. With this, we register the object, then export it to get a handle, we pass the handle to native code. When we get a handle from native code, we import it to get back to the original Dylan object (which may have moved). We can unregister it when we're all done. register-c-dylan-object(handle); %uv-handle-data(handle.raw-handle) := export-c-dylan-object(handle); ... let handle = import-c-dylan-object(%uv-handle-data(raw-handle)); apply(handle.callback, args) These are all solved problems. They can be a bit tedious and sometimes error prone, but nothing that can't be solved. It might be adventurous to migrate an existing community that wasn't prepared though.