13-Jan-2014 13:20, Rainer Schuetze пишет:
> On Sunday, 12 January 2014 at 10:40:50 UTC, Benjamin Thaut wrote:
>> Am 12.01.2014 11:27, schrieb Rainer Schuetze:
>>>
>>> I think a moving collector is currently not feasible without restricting
>>> the language a lot, probably similar to safe D and more. I'm not sure we
>>> want that in general.
>>>
>>
>> Could you give an example which part of the language would not be
>> doable with a moving collector? The only thing that comes to my mind
>> is unions and that problem can be solved by allowing the user to
>> specify manual scanning functions for structs or classes containing
>> unions.
>
> Maybe I'm too pessimistic ;-) I guess moving in general could be ok, I
> was thinking about segregating heaps by type (shared/immutable/mutable)
> and moving data between them adds restrictions. I'd like to be proven
> wrong.
>
> Some thoughts regarding a moving collector:
>

> Having to explicitely pin every pointer passed to C functions would be
> very expensive.

How would it be expensive? I don't see a need to do anything to "pin" a memory block, at the time of scanning there will be a potential pointer to it (in the stack space of C function or registers).

-- 
Dmitry Olshansky

On Monday, 13 January 2014 at 17:45:26 UTC, Dmitry Olshansky wrote:
> How would it be expensive? I don't see a need to do anything to "pin" a memory block, at the time of scanning there will be a potential pointer to it (in the stack space of C function or registers).

How do you know that it is a pointer?

13-Jan-2014 21:49, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" пишет:
> On Monday, 13 January 2014 at 17:45:26 UTC, Dmitry Olshansky wrote:
>> How would it be expensive? I don't see a need to do anything to "pin"
>> a memory block, at the time of scanning there will be a potential
>> pointer to it (in the stack space of C function or registers).
>
> How do you know that it is a pointer?
>

Precisely. Since C space has no type information you have to conservatively assume that everything can be a pointer.

-- 
Dmitry Olshansky

On Monday, 13 January 2014 at 09:20:16 UTC, Rainer Schuetze wrote:
> Maybe I'm too pessimistic ;-) I guess moving in general could be ok, I was thinking about segregating heaps by type (shared/immutable/mutable) and moving data between them adds restrictions. I'd like to be proven wrong.
>

I had some similar reflection. I'm not sure moving is worthwhile
for D. Segeregation is.

> To compete with other GCs we'd probably need write barriers to keep track of changed references (for concurrent operation or generations). There just needs to be a way to avoid having to rescan the full heap every time, it does not scale.
>

Barrier are only necessary for mutable shared reference write.

On Monday, 13 January 2014 at 17:56:12 UTC, Dmitry Olshansky wrote:
> Precisely. Since C space has no type information you have to conservatively assume that everything can be a pointer.

I think we are misunderstanding each other? I don't think a Boehm style GC can do compaction, since you cannot modify the "pointer", hence you have to "pin down" the object it possibly points to (to prevent it from moving)?

…and scanning of C data segments is insufficient anyway, since protected drivers can retain pointers that are out of reach...

On 1/12/2014 2:40 AM, Benjamin Thaut wrote:
> Am 12.01.2014 11:27, schrieb Rainer Schuetze:
>>
>> I think a moving collector is currently not feasible without restricting
>> the language a lot, probably similar to safe D and more. I'm not sure we
>> want that in general.
>>
>
> Could you give an example which part of the language would not be doable with a
> moving collector? The only thing that comes to my mind is unions and that
> problem can be solved by allowing the user to specify manual scanning functions
> for structs or classes containing unions.
>
> Also I don't think that we can create a GC which performs as good as the one of
> Java or C# if we are not willing to make the neccessary changes for a moving gc.


A moving GC is already supported by D's semantics.

Unions are dealt with by 'pinning' those objects, i.e. simply don't move them. I know this can work because I implemented a mostly copying generational collector years ago for Java. (After I invented this, someone else came out with a paper about a "mostly copying" collector, so I didn't get any credit. Oh well! But the idea is sound and it works in the real world.)

On 1/13/14 12:44 PM, Walter Bright wrote:
> On 1/12/2014 2:40 AM, Benjamin Thaut wrote:
>> Am 12.01.2014 11:27, schrieb Rainer Schuetze:
>>>
>>> I think a moving collector is currently not feasible without restricting
>>> the language a lot, probably similar to safe D and more. I'm not sure we
>>> want that in general.
>>>
>>
>> Could you give an example which part of the language would not be doable with a
>> moving collector? The only thing that comes to my mind is unions and that
>> problem can be solved by allowing the user to specify manual scanning functions
>> for structs or classes containing unions.
>>
>> Also I don't think that we can create a GC which performs as good as the one of
>> Java or C# if we are not willing to make the neccessary changes for a moving gc.
>
>
> A moving GC is already supported by D's semantics.
>
> Unions are dealt with by 'pinning' those objects, i.e. simply don't move them. I know this can work
> because I implemented a mostly copying generational collector years ago for Java. (After I invented
> this, someone else came out with a paper about a "mostly copying" collector, so I didn't get any
> credit. Oh well! But the idea is sound and it works in the real world.)

The key advantage that moving gives to a GC is to allow it to have a block of memory that it can do allocations out of by simply bumping the pointer.  When that region is full, a minor collection kicks in, moving anything still alive out to a different block of memory, then reset the region for re-use.  Pinned objects == region can't be emptied for reuse.  That leads to fragmentation and free list maintenance and you're right back with a more typical allocator.

Not to say there aren't other ways of doing things, but with random objects becoming pinnable puts a big damper on things unless you can identify all the objects that might be pinned and isolate them.  But I doubt that's really knowable up front.

13-Jan-2014 22:44, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" пишет:
> On Monday, 13 January 2014 at 17:56:12 UTC, Dmitry Olshansky wrote:
>> Precisely. Since C space has no type information you have to
>> conservatively assume that everything can be a pointer.
>
> I think we are misunderstanding each other? I don't think a Boehm style
> GC can do compaction, since you cannot modify the "pointer", hence you
> have to "pin down" the object it possibly points to (to prevent it from
> moving)?

So what? It can't move it and as such there is nothing special about it, it doesn't _cost_ anything to pin object.

-- 
Dmitry Olshansky

13-Jan-2014 22:56, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" пишет:
> …and scanning of C data segments is insufficient anyway, since protected
> drivers can retain pointers that are out of reach...

A stack is a stack is a stack.
Not that D haven't had problem with hidden pointers such as these in C heap (and not being marked explicitly).

-- 
Dmitry Olshansky