January 13, 2014 Re: Componentizing D's garbage collector | ||||
---|---|---|---|---|
| ||||
Posted in reply to Rainer Schuetze | 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 |
January 13, 2014 Re: Componentizing D's garbage collector | ||||
---|---|---|---|---|
| ||||
Posted in reply to 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?
|
January 13, 2014 Re: Componentizing D's garbage collector | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ola Fosheim Grøstad | 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 |
January 13, 2014 Re: Componentizing D's garbage collector | ||||
---|---|---|---|---|
| ||||
Posted in reply to Rainer Schuetze | 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. |
January 13, 2014 Re: Componentizing D's garbage collector | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dmitry Olshansky | 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)?
|
January 13, 2014 Re: Componentizing D's garbage collector | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ola Fosheim Grøstad | …and scanning of C data segments is insufficient anyway, since protected drivers can retain pointers that are out of reach... |
January 13, 2014 Re: Componentizing D's garbage collector | ||||
---|---|---|---|---|
| ||||
Posted in reply to Benjamin Thaut | 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.)
|
January 13, 2014 Re: Componentizing D's garbage collector | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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.
|
January 13, 2014 Re: Componentizing D's garbage collector | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ola Fosheim Grøstad | 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 |
January 13, 2014 Re: Componentizing D's garbage collector | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ola Fosheim Grøstad | 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 |
Copyright © 1999-2021 by the D Language Foundation