http://d.puremagic.com/issues/show_bug.cgi?id=3463
Steven Schveighoffer <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #91 from Steven Schveighoffer <[email protected]> 2011-04-14 05:16:41 PDT --- (In reply to comment #87) > The idea, as I understand it, is to supply a bit mask of where the pointers > are. For me, the difficulties are: > > 1. distinguishing real pointers from might-be-a-pointer (such as you might get > from union { int a; void* p; }). This is only a problem for a moving GC. In practice, unions are not very common, so the conservative scanning for unions should be very small compared to the other cases. > > 2. large static arrays, large structs/classes, structs with large static array > members, etc. > > The amount of static data dedicated to such bit arrays could get very large. Yes and no. Consider right now (although I think David fixed this), we allocate a bit for every 16 bytes of a page, even if the whole page is a block. Even for that, the ratio is very small (1 bit per 16 bytes == 1/128). I think in reality, the only common case for potentially large static data is arrays. I think the code needs some way of saying "here is an array of X elements with this bitmask". I think that should cover most cases. > I see two solutions: > > 1. if it is case (1) or (2), give up for that type and revert to the current > method of scanning that object This is exactly the opposite of what you want -- large arrays and structs are the biggest problem for the conservative GC. Whether this translates to static arrays, I'm not sure. > 2. devise a 'state machine' instead that the gc executes for a type. The state > machine has instructions like "advance n bytes to the next pointer" and "the > next pointer is ambiguous" and "execute the following sequence n times." This could be a viable solution, but I think all we need would be one descriptor type: offset x has bitmask Y repeated N times. where the offset is optional, and describes the offset from the previous bitmask. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
