www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Implementing Alternative Garbage Collector

reply "Brandon Ragland" <brandon callmemaybe.com> writes:
This is just a figurative idea, perhaps for my own amusement...

I've browsed the D runtime GC source code for the last few days 
and I'm still undecided on what the actual method of "replacing" 
the existing GC would be.

Say for example, I decided to tinker and create my own GC 
(disregard the fact that it'd be slower / faster, this is for 
learning purposes only).

Is there a way to "insert" a new GC implementation, and what is 
the actual interface the GC is using to connect to the core 
runtime of D?

I see several GC related structs, etc. kind of spit everywhere, 
and determining which one is the actual core _interface_ is 
seeming more difficult than I thought.


Any hints, or pointing to the correct direction would be very 
helpful.

 From the looks of it, it doesn't seem obvious.
Sep 02 2015
parent reply Jacob Carlborg <doob me.com> writes:
c
On 2015-09-02 18:09, Brandon Ragland wrote:
 This is just a figurative idea, perhaps for my own amusement...

 I've browsed the D runtime GC source code for the last few days and I'm
 still undecided on what the actual method of "replacing" the existing GC
 would be.

 Say for example, I decided to tinker and create my own GC (disregard the
 fact that it'd be slower / faster, this is for learning purposes only).

 Is there a way to "insert" a new GC implementation, and what is the
 actual interface the GC is using to connect to the core runtime of D?

 I see several GC related structs, etc. kind of spit everywhere, and
 determining which one is the actual core _interface_ is seeming more
 difficult than I thought.


 Any hints, or pointing to the correct direction would be very helpful.

  From the looks of it, it doesn't seem obvious.
There's a minimal example of a GC in the druntime source code [1]. For actually replacing the current one with your custom, I think the easiest would be to just implement the necessary functions in your application. They will take precedence over the ones in druntime when linking. [1] https://github.com/D-Programming-Language/druntime/blob/master/src/gcstub/gc.d -- /Jacob Carlborg
Sep 02 2015
parent reply "Brandon Ragland" <brandon callmemaybe.com> writes:
On Wednesday, 2 September 2015 at 18:25:11 UTC, Jacob Carlborg 
wrote:
 c
 On 2015-09-02 18:09, Brandon Ragland wrote:
 This is just a figurative idea, perhaps for my own amusement...

 I've browsed the D runtime GC source code for the last few 
 days and I'm
 still undecided on what the actual method of "replacing" the 
 existing GC
 would be.

 Say for example, I decided to tinker and create my own GC 
 (disregard the
 fact that it'd be slower / faster, this is for learning 
 purposes only).

 Is there a way to "insert" a new GC implementation, and what 
 is the
 actual interface the GC is using to connect to the core 
 runtime of D?

 I see several GC related structs, etc. kind of spit 
 everywhere, and
 determining which one is the actual core _interface_ is 
 seeming more
 difficult than I thought.


 Any hints, or pointing to the correct direction would be very 
 helpful.

  From the looks of it, it doesn't seem obvious.
There's a minimal example of a GC in the druntime source code [1]. For actually replacing the current one with your custom, I think the easiest would be to just implement the necessary functions in your application. They will take precedence over the ones in druntime when linking. [1] https://github.com/D-Programming-Language/druntime/blob/master/src/gcstub/gc.d
While that may be true, if the purpose was to ensure tracking and collection of objects / arrays created with the new expression, how would one do that without knowledge of the actual implementation and the interface? Same would go for slicing operations, which would be difficult to track. You'd have to pass a pointer to that new object onto the custom GC, or it will never see it. Quick way to have huge memory leaks...
Sep 02 2015
parent reply Jacob Carlborg <doob me.com> writes:
On 2015-09-02 22:13, Brandon Ragland wrote:
 On Wednesday, 2 September 2015 at 18:25:11 UTC, Jacob Carlborg wrote:
 [1]
 https://github.com/D-Programming-Language/druntime/blob/master/src/gcstub/gc.d
While that may be true, if the purpose was to ensure tracking and collection of objects / arrays created with the new expression, how would one do that without knowledge of the actual implementation and the interface? Same would go for slicing operations, which would be difficult to track. You'd have to pass a pointer to that new object onto the custom GC, or it will never see it. Quick way to have huge memory leaks...
I'm not sure I understand you're reply. You asked for the interface to the GC, as far as I know the above link contains the interface for the GC. That is, all the extern (C) functions. As far as the "new" expression, technically it has nothing to do with the GC. The "new" expression is lowered to a call to "_d_newclass" [1], which in the current implementation then calls the GC. I recommend you having a look in the "rt" package. [1] https://github.com/D-Programming-Language/druntime/blob/master/src/rt/lifetime.d#L71 -- /Jacob Carlborg
Sep 02 2015
parent "Brandon Ragland" <brandon callmemaybe.com> writes:
On Thursday, 3 September 2015 at 06:36:17 UTC, Jacob Carlborg 
wrote:
 On 2015-09-02 22:13, Brandon Ragland wrote:
 On Wednesday, 2 September 2015 at 18:25:11 UTC, Jacob Carlborg 
 wrote:
 [1]
 https://github.com/D-Programming-Language/druntime/blob/master/src/gcstub/gc.d
While that may be true, if the purpose was to ensure tracking and collection of objects / arrays created with the new expression, how would one do that without knowledge of the actual implementation and the interface? Same would go for slicing operations, which would be difficult to track. You'd have to pass a pointer to that new object onto the custom GC, or it will never see it. Quick way to have huge memory leaks...
I'm not sure I understand you're reply. You asked for the interface to the GC, as far as I know the above link contains the interface for the GC. That is, all the extern (C) functions. As far as the "new" expression, technically it has nothing to do with the GC. The "new" expression is lowered to a call to "_d_newclass" [1], which in the current implementation then calls the GC. I recommend you having a look in the "rt" package. [1] https://github.com/D-Programming-Language/druntime/blob/master/src/rt/lifetime.d#L71
That links answers many questions. To be honest, I don't truly understand how D uses the GC or it's interface, which is part of the reason why I want to attempt to link one myself. It's for learning purposes, which could help shed some light on the GC usefulness in D (for myself of-course) I appreciate the link to RT, that actually explains a lot. I see multiple places where the GC is called in RT, which helps explain the Proxy GC struct, and how that is being used as the interface to the actual GC. The Stub GC you linked earlier is helpful to a degree, and where I will start.
Sep 03 2015