• Daniel Keep (30/30) Mar 18 2009 Just thinking out loud; no proposals or anything. :)

Daniel Keep <daniel.keep.lists gmail.com> writes:

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