Just thinking out loud; no proposals or anything.  :)

I've been floating around the idea of doing some "for fun" programming on my Wii.  Of course, I'd like to use D.  One of the concerns I have is that the Wii has a tiny amount of memory compared to a PC (about 76 MB or so) so you don't want to generate too much garbage.

There seem to be three kinds of allocations: big and/or long-lived allocations, which aren't much of an issue; medium-lived objects that get allocated, used and mutated, then destroyed (scope deals with most of these,) and transient garbage.  Transient garbage includes side-effects of calling other functions or even language features.

We really don't have a "good" way of dealing with these tiny, short-lived allocations.  One thought I had was to extend the GC to include a new method:

auto result = GC.scoped( /* lazy expr, function ptr or delegate */ );

This would call the given code and return the result.  Just before it returns, however, it makes a deep-copy of the result and then nukes all the pages it allocated during the call.

Deep copying isn't a tremendous problem since we know the type of the result, and we know which pointers are inside the to-be-nuked pages. The only fly in the ointment would be if we'd stored a reference to the to-be-nuked pages in external variables, like a global.

Which is exactly what a pure function is prohibited from doing.

Also note that the above scoped call is basically doing what a compacting GC does: compacting live allocations, and then dropping the garbage off the end.

This brings up two interesting questions:

1. Should D 2.0 have a similar GC.scoped call?

2. Should D 2.0 do automatic compaction for pure functions?

Thoughts?

  -- Daniel