www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Typed GC

reply Shammah Chancellor <anonymous coward.com> writes:
With all the talk of garbage collection.  I was wondering if it would 
be useful to make the GC typed.  If it was typed, it maybe be possible 
to make it more efficient via type information, (such as only scanning 
reference fields).   Also, it could have access to attribute 
information if applicable.

-S.
Feb 12 2014
next sibling parent "Eric Suen" <eric.suen.tech gmail.com> writes:
That's called precise GC...

Off topic: Toward Go 1.3: 100% precise GC Finally

http://www.reddit.com/r/programming/comments/1xmh7j/toward_go_13_100_precise_gc_finally/

"Shammah Chancellor" ...
 With all the talk of garbage collection.  I was wondering if it would be
useful to make the GC typed.  If it was 
 typed, it maybe be possible to make it more efficient via type information,
(such as only scanning reference fields). 
 Also, it could have access to attribute information if applicable.

 -S.
 

Feb 12 2014
prev sibling next sibling parent reply "thedeemon" <dlang thedeemon.com> writes:
On Wednesday, 12 February 2014 at 12:11:04 UTC, Shammah 
Chancellor wrote:
 With all the talk of garbage collection.  I was wondering if it 
 would be useful to make the GC typed.  If it was typed, it 
 maybe be possible to make it more efficient via type 
 information, (such as only scanning reference fields).   Also, 
 it could have access to attribute information if applicable.

 -S.

This is how "almost precise" GC used in VisualD works. Type information is used to mark all pointers in most heap objects, but objects on stack and closures are still scanned conservatively, IIRC. Unfortunately this GC is not included in the main D distribution, probably because it's considered to not be tested well enough.
Feb 12 2014
parent reply Shammah Chancellor <anonymous coward.com> writes:
On 2014-02-12 17:50:24 +0000, thedeemon said:

 On Wednesday, 12 February 2014 at 12:11:04 UTC, Shammah Chancellor wrote:
 With all the talk of garbage collection.  I was wondering if it would 
 be useful to make the GC typed.  If it was typed, it maybe be possible 
 to make it more efficient via type information, (such as only scanning 
 reference fields).   Also, it could have access to attribute 
 information if applicable.
 
 -S.

This is how "almost precise" GC used in VisualD works. Type information is used to mark all pointers in most heap objects, but objects on stack and closures are still scanned conservatively, IIRC. Unfortunately this GC is not included in the main D distribution, probably because it's considered to not be tested well enough.

How's that work? The gc interface right now in core.memory is not templated. -S.
Feb 12 2014
parent Benjamin Thaut <code benjamin-thaut.de> writes:
Am 13.02.2014 02:46, schrieb Shammah Chancellor:
 On 2014-02-12 17:50:24 +0000, thedeemon said:

 On Wednesday, 12 February 2014 at 12:11:04 UTC, Shammah Chancellor wrote:
 With all the talk of garbage collection.  I was wondering if it would
 be useful to make the GC typed.  If it was typed, it maybe be
 possible to make it more efficient via type information, (such as
 only scanning reference fields).   Also, it could have access to
 attribute information if applicable.

 -S.

This is how "almost precise" GC used in VisualD works. Type information is used to mark all pointers in most heap objects, but objects on stack and closures are still scanned conservatively, IIRC. Unfortunately this GC is not included in the main D distribution, probably because it's considered to not be tested well enough.

How's that work? The gc interface right now in core.memory is not templated. -S.

It is using object.RTInfo
Feb 12 2014
prev sibling next sibling parent "Frustrated" <c1514843 drdrb.com> writes:
On Wednesday, 12 February 2014 at 17:50:25 UTC, thedeemon wrote:
 On Wednesday, 12 February 2014 at 12:11:04 UTC, Shammah 
 Chancellor wrote:
 With all the talk of garbage collection.  I was wondering if 
 it would be useful to make the GC typed.  If it was typed, it 
 maybe be possible to make it more efficient via type 
 information, (such as only scanning reference fields).   Also, 
 it could have access to attribute information if applicable.

 -S.

This is how "almost precise" GC used in VisualD works. Type information is used to mark all pointers in most heap objects, but objects on stack and closures are still scanned conservatively, IIRC. Unfortunately this GC is not included in the main D distribution, probably because it's considered to not be tested well enough.

But if we could drop in any gc version then it would't matter. It would be nice to be able to choose your own poison rather than it forced down your throat... that that it matters... I just like happy endings!
Feb 12 2014
prev sibling next sibling parent "thedeemon" <dlang thedeemon.com> writes:
On Thursday, 13 February 2014 at 01:46:26 UTC, Shammah Chancellor 
wrote:
 On 2014-02-12 17:50:24 +0000, thedeemon said:

 This is how "almost precise" GC used in VisualD works. Type 
 information is used to mark all pointers in most heap objects, 
 but objects on stack and closures are still scanned 
 conservatively, IIRC. Unfortunately this GC is not included in 
 the  main D distribution, probably because it's considered to 
 not be tested well enough.

How's that work?

Rainer had to patch dmd in order for this to work, to add more type information and make the pointer bitmap filling.
Feb 12 2014
prev sibling next sibling parent reply evansl <cppljevans suddenlink.net> writes:
On 02/12/14 06:11, Shammah Chancellor wrote:
 With all the talk of garbage collection.  I was wondering if it would be
 useful to make the GC typed.  If it was typed, it maybe be possible to
 make it more efficient via type information, (such as only scanning
 reference fields).   Also, it could have access to attribute information
 if applicable.

 -S.

In an earlier thread, Andrei proposed: I suspect that allocating and manipulating objects on the GC heap in particular may have certain restrictions. One possibility to avoid such restrictions is to have a function typify(T)(void* p) which ascribes type T to heap location p. which would be one way to at least record the type of each memory location. However, later posts in that thread indicated there were problems with where to store that information. I thought you could store it in the heap along side the pointed to object; however, that seemed to have problems, according to this post: http://forum.dlang.org/thread/lao9fn$1d70$1 digitalmars.com?page=12#post-jgommvkndygzcpxxotly:40forum.dlang.org So, the idea seems good, but I'd guess implementation is problematic. At least that's what I guess from the referenced posts. -regards, Larry
Feb 26 2014
parent reply evansl <cppljevans suddenlink.net> writes:
On 02/26/14 10:25, evansl wrote:
 On 02/12/14 06:11, Shammah Chancellor wrote:
 With all the talk of garbage collection.  I was wondering if it would be
 useful to make the GC typed.  If it was typed, it maybe be possible to
 make it more efficient via type information, (such as only scanning
 reference fields).   Also, it could have access to attribute information
 if applicable.

 -S.

In an earlier thread, Andrei proposed: I suspect that allocating and manipulating objects on the GC heap in particular may have certain restrictions. One possibility to avoid such restrictions is to have a function typify(T)(void* p) which ascribes type T to heap location p. which would be one way to at least record the type of each memory location. However, later posts in that thread indicated there were problems with where to store that information. I thought you could store it in the heap along side the pointed to object; however, that seemed to have problems, according to this post: http://forum.dlang.org/thread/lao9fn$1d70$1 digitalmars.com?page=12#post-jgommvkndygzcpxxotly:40forum.dlang.org So, the idea seems good, but I'd guess implementation is problematic. At least that's what I guess from the referenced posts. -regards, Larry

http://forum.dlang.org/post/ldhquc$11ec$1 digitalmars.com and then the druntime code: https://github.com/D-Programming-Language/druntime/blob/e47a00bff935c3f079bb567a6ec97663ba384487/src/object_.d#L2629 which contains: immutable(void)* m_RTInfo; // data for precise GC override property immutable(void)* rtInfo() const { return m_RTInfo; } So, I guess m_RTInfo contains information from which the pointers within the object can be precisely found. Sorry for noise :( -Larry
Feb 26 2014
parent Shammah Chancellor <anonymous coward.com> writes:
On 2014-02-26 16:51:25 +0000, evansl said:

 On 02/26/14 10:25, evansl wrote:
 On 02/12/14 06:11, Shammah Chancellor wrote:
 With all the talk of garbage collection.  I was wondering if it would be
 useful to make the GC typed.  If it was typed, it maybe be possible to
 make it more efficient via type information, (such as only scanning
 reference fields).   Also, it could have access to attribute information
 if applicable.
 
 -S.
 

In an earlier thread, Andrei proposed: I suspect that allocating and manipulating objects on the GC heap in particular may have certain restrictions. One possibility to avoid such restrictions is to have a function typify(T)(void* p) which ascribes type T to heap location p. which would be one way to at least record the type of each memory location. However, later posts in that thread indicated there were problems with where to store that information. I thought you could store it in the heap along side the pointed to object; however, that seemed to have problems, according to this post: http://forum.dlang.org/thread/lao9fn$1d70$1 digitalmars.com?page=12#post-jgommvkndygzcpxxot y:40forum.dlang.org So, the idea seems good, but I'd guess implementation is problematic. At least that's what I guess from the referenced posts. -regards, Larry

http://forum.dlang.org/post/ldhquc$11ec$1 digitalmars.com and then the druntime code: https://github.com/D-Programming-Language/druntime/blob/e47a00bff935c3f079bb567a6ec97663ba384487 src/object_.d#L2629 which contains: immutable(void)* m_RTInfo; // data for precise GC override property immutable(void)* rtInfo() const { return m_RTInfo; } So, I guess m_RTInfo contains information from which the pointers within the object can be precisely found. Sorry for noise :( -Larry

No problem, thanks for the reply. However, I was suggesting that new be given type info at compile time in order to add some optimization to the GC there. -SC
Feb 26 2014
prev sibling next sibling parent "w0rp" <devw0rp gmail.com> writes:
Having precise GC in D eventually would be cool. Not having to 
worry about false pointers is always good.
Feb 27 2014
prev sibling parent "Namespace" <rswhite4 googlemail.com> writes:
Would be so nice if we finally fix issue 12256 
(https://d.puremagic.com/issues/show_bug.cgi?id=12256).
I hate it...
Feb 27 2014