--- Comment #37 from Leandro Lucarella <llu...@gmail.com> 2010-07-22 17:54:38
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: -------