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.

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.
> 

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.

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!

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.

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

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.

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.
>
Hi Shammah,

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

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.
>>
> Hi Shammah,
>
> 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
>
OOPS.  Just read Benjamin's post:

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

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.
>>> 
>> Hi Shammah,
>> 
>> 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
>> 
> OOPS.  Just read Benjamin's post:
> 
> 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