[Issue 3463] Integrate Precise Heap Scanning Into the GC

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=3463



--- Comment #37 from Leandro Lucarella <llucax at gmail.com> 2010-07-22 17:54:38 PDT ---
BTW, I just realized that this type information scheme doesn't enable the GC to
move data around (i.e. it doesn't open the door to moving collectors) since the
distinction between *is* a pointer and *may be* a pointer is not present.

This difference is necessary for knowing when you can move things around, since
a block pointed to by a *may be* a pointer should be pinned, because you can't
update the word suspected to be a pointer (because in case is not, you are
corrupting user's memory). Only block pointed to by *is* a pointer words are
candidates for moving.

Maybe considering that this involves a change in the compiler, it would be a
good opportunity to finally open the door to moving collectors. Unfortunately
this means more type information is necessary. Maybe 2 bitmasks can be used, a
"scan" mask (that can take over the NO_SCAN attribute) and a "pointer" mask. A
word marked as "scan" (i.e. "scan" bit == 1) should be scanned but might be a
pointer or not (like the current bitmask proposed in this patch); a word marked
"pointer (i.e. "pointer bit == 1) is guaranteed to be a pointer and the GC is
allowed to update it if the pointed to block is moved.

So a real pointer should have both scan and pointer set to 1 (yeah, scan is
redundant, but I can't think of a better representation), and an union should
have only scan set to 1. I don't know what to do with void* though, since is
very common to use it as a "safe-buffer" instead of a real pointer array. The
safe bet is to keep it only with the "scan" bit, I guess.

I didn't think a lot if this organization of the information is the best for
the GC implementator, but it's simple and opens the door to experimentation, so
I think it's better to have a possibility even when is not the better solution
than not having anything; the interface can be refined in the future.

Since you are already playing with the compiler, do you think it's possible to
change the compiler to provide this information?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------