compiler support added for precise GC

[Alex Rønne Petersen]

On 16-04-2012 20:02, Sean Kelly wrote:
> On Apr 16, 2012, at 2:25 AM, Walter Bright wrote:
>
>> On 4/16/2012 2:05 AM, deadalnix wrote:
>>> Having this template into object.d seems problematic to me. It is now quite hard
>>> to provide any custom GC implementation without messing with Druntime.
>>>
>>> Providing a user created GC should be as easy as possible.
>>
>> It's never going to be easy for anyone to just write their own GC, especially one that works better than one a lot of people have spent a lot of time on.
>
> What I've been going for is to have all functionality that requires knowledge of code generation, (most) platform specifics, etc, live in the compiler runtime portion of Druntime (i.e. in the "rt" package).  This is all stuff that the compiler writer knows by necessity, and the GC writer shouldn't be required to know it as well.
>
> As for pointer maps, I think it's reasonable to establish a format that these will be made available to the GC, and for them to come from elsewhere in the runtime.  I realize that different GC implementations may prefer different formats, but hopefully we can settle on one that's pretty generally usable and efficient.  I'd really rather avoid expecting GC writers to know how to meta-process D types to statically generate this themselves.  Moving this into the GC would also eliminate the possibility of having the GC chosen at link-time, which is something that's currently still an option.
>

I think we can safely settle on bitmaps for this. Most real world GCs 
use this kind of strategy.

>>> I think this is again solving an implementation issue by a language design
>>> decision. Ultimately the useless code bloat must be handled by the toolchain
>>> anyway.
>>
>> We gotta work with what we have.
>>
>>>> 6. I suggest the GCInfo pointer be stored at the end of the allocated
>>>> block, as then it won't affect the alignment of the allocated data.
>>>
>>> This very swap unfriendly. Many pages will have to be unswapped/swapped back in
>>> the marking process, even if it is 100% useless for data that doesn't contains
>>> pointers.
>>
>> I think there's a misunderstanding. The GC allocates by powers of 2. So a 22 byte struct will be allocated in a 32 byte block, and the GCInfo pointer can go at the end of that. That will not cause swapping.
>>
>> As for data that has no pointers, something has to indicate that. Of course, another strategy is to allocate such data in separate pools. In fact, that might be an excellent idea, as such pools would never have to be read (i.e. swapped in, loaded into cache) during the mark/sweep process.
>
> This is obviously all for the current GC anyway.  Another implementation may be better off storing things elsewhere.


-- 
- Alex