On 1/13/14 12:44 PM, Walter Bright wrote:
On 1/12/2014 2:40 AM, Benjamin Thaut wrote:
Am 12.01.2014 11:27, schrieb Rainer Schuetze:
I think a moving collector is currently not feasible without restricting
the language a lot, probably similar to safe D and more. I'm not sure we
want that in general.
Could you give an example which part of the language would not be doable with a
moving collector? The only thing that comes to my mind is unions and that
problem can be solved by allowing the user to specify manual scanning functions
for structs or classes containing unions.
Also I don't think that we can create a GC which performs as good as the one of
Java or C# if we are not willing to make the neccessary changes for a moving gc.
A moving GC is already supported by D's semantics.
Unions are dealt with by 'pinning' those objects, i.e. simply don't move them.
I know this can work
because I implemented a mostly copying generational collector years ago for
Java. (After I invented
this, someone else came out with a paper about a "mostly copying" collector, so
I didn't get any
credit. Oh well! But the idea is sound and it works in the real world.)
The key advantage that moving gives to a GC is to allow it to have a block of memory that it can do
allocations out of by simply bumping the pointer. When that region is full, a minor collection
kicks in, moving anything still alive out to a different block of memory, then reset the region for
re-use. Pinned objects == region can't be emptied for reuse. That leads to fragmentation and free
list maintenance and you're right back with a more typical allocator.
Not to say there aren't other ways of doing things, but with random objects becoming pinnable puts a
big damper on things unless you can identify all the objects that might be pinned and isolate them.
But I doubt that's really knowable up front.
