I'd like to add a feature to the GC allowing it to track externally-allocated memory. The simplified use case is this:

	struct S { ... }
	extern (C) S* s_create();
	extern (C) void s_destroy(S*);

	void main() {
		S* s = s_create();
		GC.track(s, S.sizeof, &s_destroy, false/*no scan*/);
		...
	}

By calling "GC.track", the GC would start tracking pointers pointing to the specified memory block during the mark phase and then call the "s_destroy" function as the finalizer when it is no longer reachable. I looked at how the GC works, and one idea that pops to mind is to add special Pool that would cover pages corresponding to those external objects, a Pool that would be created as needed when adding external blocks through "GC.track" and that would not be available for allocation.

I realize this solution makes it be impossible to track blocks at a finer granularity than aligned 16 bytes, but I can live with that constrain.

Does this approach makes sense? any concern? any better idea?

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/

Why is this needed?  And FWIW this should be possible today by creating a class that references this memory and calls free() or whatever in its dtor.

On May 22, 2011, at 3:38 AM, Michel Fortin wrote:

> I'd like to add a feature to the GC allowing it to track externally-allocated memory. The simplified use case is this:
> 
> 	struct S { ... }
> 	extern (C) S* s_create();
> 	extern (C) void s_destroy(S*);
> 
> 	void main() {
> 		S* s = s_create();
> 		GC.track(s, S.sizeof, &s_destroy, false/*no scan*/);
> 		...
> 	}
> 
> By calling "GC.track", the GC would start tracking pointers pointing to the specified memory block during the mark phase and then call the "s_destroy" function as the finalizer when it is no longer reachable. I looked at how the GC works, and one idea that pops to mind is to add special Pool that would cover pages corresponding to those external objects, a Pool that would be created as needed when adding external blocks through "GC.track" and that would not be available for allocation.
> 
> I realize this solution makes it be impossible to track blocks at a finer granularity than aligned 16 bytes, but I can live with that constrain.
> 
> Does this approach makes sense? any concern? any better idea?
> 
> -- 
> Michel Fortin
> michel.fortin at michelf.com
> http://michelf.com/
> 
> 
> 
> _______________________________________________
> D-runtime mailing list
> D-runtime at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/d-runtime

Le 2011-05-27 ? 13:24, Sean Kelly a ?crit :

> Why is this needed?

Tracking Objective-C objects in my extern(Objective-C) addition to the compiler. The compiler would add the necessary calls to a runtime function that'd to make these Objective-C objects tracked by the GC.

> And FWIW this should be possible today by creating a class that references this memory and calls free() or whatever in its dtor.

Indeed. But that's not really an option in this case. Even if the compiler generated those wrappers automatically, this detail can't realistically be hidden away from the user and having two addresses for one object with two kinds of pointers you should't mix would be quite complicated and confusing.

Other options would be:

1. ask the user to do manual memory management with retain/release/autorelease
2. make the compiler smart enough to do retain/release/autorelease by itself most of the time, with some overrides so you can avoid cycles and such.

But having the D GC tracking Objective-C objects would allow them to behave just like regular D objects pretty much everywhere, which is basically my goal for this project.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/