More radical ideas about gc and reference counting

[Dmitry Olshansky via Digitalmars-d]

11-May-2014 23:16, John Colvin пишет:
> On Sunday, 11 May 2014 at 18:18:41 UTC, Rainer Schuetze wrote:
>>
>>
>> On 11.05.2014 10:22, Benjamin Thaut wrote:
>>> Am 10.05.2014 19:54, schrieb Andrei Alexandrescu:
>>>>
>>>>> The next sentence goes on to list the advantages of RC (issues we have
>>>>> wrestled with, like destructors), and then goes on to say the recent
>>>>> awesome RC is within 10% of "the fastest tracing collectors".
>>>>> Are you suggesting that D's GC is among 'the fastest tracing
>>>>> collectors'? Is such a GC possible in D?
>>>>
>>>> I believe it is.
>>>>
>>>
>>> While it might be possible to implement a good GC in D it would require
>>> major changes in the language and its librariers. In my opinion it would
>>> be way more work to implement a propper GC than to implement ARC.
>>>
>>> Every state of the art GC requires percise knowdelge of _all_ pointers.
>>> And thats exactly what we currently don't have in D.
>>
>> I think most garbage collectors can work with a number of false
>> pointers. The referenced memory area has to be treated as pinned and
>> cannot be moved. Limiting the false pointers to stack and registers
>> seems like a compromise, though most of the stack could even be
>> annotated. Code for this does already exist in the debug info
>> generation, though I suspect stack tracing could be unreliable.
>>
>> Here's my current stance on the GC discussions:
>>
>> I agree that the current GC is pretty lame, even if it were precise.
>> "Stop-the-World" with complete tracing does not work for any
>> interactive application that uses more than a few hundred MB of
>> garbage collected memory (with or without soft-realtime requirements).
>> Other applications with larger allocation requirements are easily
>> dominated by collection time. Proposing to use manual memory
>> management instead is admitting failure to me.
>>
>> For a reasonable GC I currently see 2 possible directions:
>> Coventry
>> 1. Use a scheme that takes a snapshot of the heap, stack and registers
>> at the moment of collection and do the actual collection in another
>> thread/process while the application can continue to run. This is the
>> way Leandro Lucarellas concurrent GC works
>> (http://dconf.org/2013/talks/lucarella.html), but it relies on "fork"
>> that doesn't exist on every OS/architecture. A manual copy of the
>> memory won't scale to very large memory, though it might be compressed
>> to possible pointers. Worst case it will need twice as much memory as
>> the current heap.
>
> a) Can't we do our own specialised alternative, instead of doing
> something as heavyweight as fork?

Provided heap was allocated as one big mmap-ed region (or File mapping 
in Win32) it should be straightforward to remap it as Copy-on-Write. 
This would though reduce virtual memory available in half (if not more 
provided we'd want to leave some space for C's malloc).

Would be cool to find a way to the allocation of thread stacks... else 
we'd have to copy them while threads are frozen.



-- 
Dmitry Olshansky