[Issue 3463] Integrate Precise Heap Scanning Into the GC

[d-bugmail at puremagic.com]

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


Steven Schveighoffer <schveiguy at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schveiguy at yahoo.com


--- Comment #91 from Steven Schveighoffer <schveiguy at yahoo.com> 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: -------