January 03, 2013
On Thursday, 3 January 2013 at 10:17:19 UTC, deadalnix wrote:
> Generational seems completely unrealistic.

Why?
January 03, 2013
On Thursday, 3 January 2013 at 11:26:11 UTC, Thiez wrote:
> On Thursday, 3 January 2013 at 10:17:19 UTC, deadalnix wrote:
>> Generational seems completely unrealistic.
>
> Why?

Tracking reference from old gen to new gen require read/write barriers.
Plus, it is unclear what the win is, generational GC is way less interesting when the GC cannot move.
January 03, 2013
On 2013-01-03, 12:40, deadalnix wrote:

> On Thursday, 3 January 2013 at 11:26:11 UTC, Thiez wrote:
>> On Thursday, 3 January 2013 at 10:17:19 UTC, deadalnix wrote:
>>> Generational seems completely unrealistic.
>>
>> Why?
>
> Tracking reference from old gen to new gen require read/write barriers.
> Plus, it is unclear what the win is, generational GC is way less interesting when the GC cannot move.

The read/write barriers are a problem. However, D is designed to allow a
moving collector, at least in some cases.

-- 
Simen
January 03, 2013
On Thursday, 3 January 2013 at 11:40:37 UTC, deadalnix wrote:
> On Thursday, 3 January 2013 at 11:26:11 UTC, Thiez wrote:
>> On Thursday, 3 January 2013 at 10:17:19 UTC, deadalnix wrote:
>>> Generational seems completely unrealistic.
>>
>> Why?
>
> Tracking reference from old gen to new gen require read/write barriers.
> Plus, it is unclear what the win is, generational GC is way less interesting when the GC cannot move.

Last time I talked with Walter (on reddit) regarding this he mentioned papers on "mostly copying GCs" where one can have a generational imprecise GC which moves most of the data but not all of it. For example, without stack maps we don't know where in the stack are pointers, so we don't move objects possibly referenced from stack. However those referenced only from the heap can be moved since we have precise heap info. I recall this is the current situation of Rainer's mostly precise GC used in VisualD - it has precise maps of the heap but not of the stack.

+1 to better GC as a project. An easier but still possibly interesting goal would be changing current (or better Rainer's) GC to use parallel marking and lazy sweeping, same things that were done for Ruby interpreter recently. That should make GC pauses much shorter and it doesn't require rewriting most of the GC.
January 03, 2013
On Thursday, 3 January 2013 at 18:54:32 UTC, thedeemon wrote:
> +1 to better GC as a project. An easier but still possibly interesting goal would be changing current (or better Rainer's) GC to use parallel marking and lazy sweeping, same things that were done for Ruby interpreter recently. That should make GC pauses much shorter and it doesn't require rewriting most of the GC.

I think we'd better look for performance boost in concurrency than parallelism here. Both TL and immutable are very concurrent GC friendly.
1 2
Next ›   Last »