"The D Programming Language" (TDPL) p.178 asserts the following.

"The objects themselves stay put, that is their locations in memory never change after creation."

I take this to mean that the D garbage collector doesn't move live objects and adjust all references to them the way that some garbage collectors do. That is to say, the addresses of objects are not changed by the garbage collector.

Does D guarantee this?

On 2013-05-31, 18:31, Carl Sturtivant wrote:

>
> "The D Programming Language" (TDPL) p.178 asserts the following.
>
> "The objects themselves stay put, that is their locations in memory never change after creation."
>
> I take this to mean that the D garbage collector doesn't move live objects and adjust all references to them the way that some garbage collectors do. That is to say, the addresses of objects are not changed by the garbage collector.
>
> Does D guarantee this?

The current D GC does guarantee this. Some future collectors might not,
but there will always be implementations that guarantee it.

-- 
Simen

On Friday, May 31, 2013 18:31:38 Carl Sturtivant wrote:
> "The D Programming Language" (TDPL) p.178 asserts the following.
> 
> "The objects themselves stay put, that is their locations in memory never change after creation."
> 
> I take this to mean that the D garbage collector doesn't move live objects and adjust all references to them the way that some garbage collectors do. That is to say, the addresses of objects are not changed by the garbage collector.
> 
> Does D guarantee this?

I don't believe that there is any such guarantee in the language. Structs on the heap get moved around all the time, so having objects with references to themselves is effectively disallowed. The GC does not currently ever move any objects, but I don't believe that the language itself guarantees that it never will. It may be that in the future it would, though it's unlikely given some of the technical difficulties caused by having unmanaged pointers and void* and whatnot. Languages which run in a VM and are restricted to managed pointers are able to make many more assumptions than D is, making it much easier for them to do moveable garbage collectors.

- Jonathan M Davis

Carl Sturtivant:

> Does D guarantee this?

In theory D is designed to allow a moving garbage collector. The current GC doesn't move objects.

Bye,
bearophile

On Friday, 31 May 2013 at 17:14:52 UTC, Jonathan M Davis wrote:
> On Friday, May 31, 2013 18:31:38 Carl Sturtivant wrote:
>> "The D Programming Language" (TDPL) p.178 asserts the following.
>> 
>> "The objects themselves stay put, that is their locations in
>> memory never change after creation."
>> 
>> I take this to mean that the D garbage collector doesn't move
>> live objects and adjust all references to them the way that some
>> garbage collectors do. That is to say, the addresses of objects
>> are not changed by the garbage collector.
>> 
>> Does D guarantee this?
>
> I don't believe that there is any such guarantee in the language. Structs on
> the heap get moved around all the time, so having objects with references to
> themselves is effectively disallowed. The GC does not currently ever move any
> objects, but I don't believe that the language itself guarantees that it never
> will. It may be that in the future it would, though it's unlikely given some
> of the technical difficulties caused by having unmanaged pointers and void* and
> whatnot. Languages which run in a VM and are restricted to managed pointers
> are able to make many more assumptions than D is, making it much easier for
> them to do moveable garbage collectors.
>
> - Jonathan M Davis

I assume you mean structs on the stack rather than on the heap - structs on the heap are never moved currently.

On Friday, May 31, 2013 20:58:14 Diggory wrote:
> I assume you mean structs on the stack rather than on the heap - structs on the heap are never moved currently.

Yes. I mistyped. Sorry about that.

- Jonathan M Davis

On Friday, 31 May 2013 at 16:31:39 UTC, Carl Sturtivant wrote:
>
> "The D Programming Language" (TDPL) p.178 asserts the following.
>
> "The objects themselves stay put, that is their locations in memory never change after creation."
>
> I take this to mean that the D garbage collector doesn't move live objects and adjust all references to them the way that some garbage collectors do. That is to say, the addresses of objects are not changed by the garbage collector.
>
> Does D guarantee this?

No. Quoted from the D website:

http://dlang.org/garbage.html

"Although D does not currently use a moving garbage collector, by following the rules listed above one can be implemented. No special action is required to pin objects. A moving collector will only move objects for which there are no ambiguous references, and for which it can update those references. All other objects will be automatically pinned. "

I'll assume you can not move immutable pointers. Immutable pointers are not mentioned on that page. (except in the index left :)

On Saturday, 1 June 2013 at 08:11:05 UTC, sclytrack wrote:
> On Friday, 31 May 2013 at 16:31:39 UTC, Carl Sturtivant wrote:
>>
>> "The D Programming Language" (TDPL) p.178 asserts the following.
>>
>> "The objects themselves stay put, that is their locations in memory never change after creation."
>>
>> I take this to mean that the D garbage collector doesn't move live objects and adjust all references to them the way that some garbage collectors do. That is to say, the addresses of objects are not changed by the garbage collector.
>>
>> Does D guarantee this?
>
> No. Quoted from the D website:
>
> http://dlang.org/garbage.html
>
> "Although D does not currently use a moving garbage collector, by following the rules listed above one can be implemented. No special action is required to pin objects. A moving collector will only move objects for which there are no ambiguous references, and for which it can update those references. All other objects will be automatically pinned. "
>
> I'll assume you can not move immutable pointers. Immutable pointers are not mentioned on that page. (except in the index left :)

Actually that's wrong - a moving GC would break everything in D since the GC cannot know if there are any ambiguous references. As soon as you pass a pointer to an external function there's no way for the GC to know if that pointer or any pointers accessible from it will ever be safe to move again. Pinning has to be explicit or it doesn't work, and currently all of phobos and druntime is implemented without it.