On Saturday, 30 October 2021 at 16:55:03 UTC, Steven Schveighoffer wrote:

??? The same way it does for all other references.

I think either you misunderstood me, or I misunderstood you.

On 10/30/21 1:38 PM, Stanislav Blinov wrote:

You said "deallocating unreferenced elements". I thought you meant elements unreferenced by the AA.

What I mean is, the AA isn't going to change implementations where it now deallocates values that may still have existing references. If that's the case, we can state that in the docs.

e.g.:

Removing a key does not deallocate the value that was removed. The value's lifetime is managed by the GC and will be alive until there are no references to that value.

-Steve

On Saturday, 30 October 2021 at 17:45:57 UTC, Steven Schveighoffer wrote:

Yup, I misunderstood you :)

:whateveritistodoathumbsuphere:

On Saturday, 30 October 2021 at 00:52:23 UTC, Imperatorn wrote:

I did small test and it printed the same values three times so even rehash doesn't change the address of the value:

            long[long] aa = [0:0];
            writeln(&aa[0]);
            foreach(i; 0 .. 100_000_000)
                    aa[i]=i;
            writeln(&aa[0]);
            aa.rehash;
            writeln(&aa[0]);

So it seems pretty safe to store a pointer to a value in AA. And I agree that this should definitely be documented.

On Saturday, 30 October 2021 at 18:31:16 UTC, Andrey Zherikov wrote:

Address itself may change though. While the AA won't move stuff around, a GC might. I don't think current GC moves anything, but it's definitely allowed to. Which would be transparent to your code so long as you don't depend on the value of address itself :)

https://dlang.org/spec/garbage.html#pointers_and_gc

On Saturday, 30 October 2021 at 20:05:17 UTC, Stanislav Blinov wrote:

What test could be written to verify the behaviour?

On Saturday, 30 October 2021 at 20:19:58 UTC, Imperatorn wrote:

Assuming the GC was moving?

You'd need a loop allocating different sizes, storing the addresses somewhere the GC won't see (i.e. in memory allocated not with the GC: malloc, VirtualAlloc, mmap...), orphaning some allocations, repeating a bunch of times, and then comparing addresses of remaining allocations with stored ones.

Behavior would very much depend on the GC implementation, so would a concrete test. Point is, it's allowed to move so we have to assume it would even if it doesn't, and relying on it not moving (i.e. depending on concrete addresses) is UB.

On 10/30/21 2:31 PM, Andrey Zherikov wrote:

             long[long] aa = [0:0];
             writeln(&aa[0]);
             foreach(i; 0 .. 100_000_000)
                     aa[i]=i;
             writeln(&aa[0]);
             aa.rehash;
             writeln(&aa[0]);

Here is the rehash code, it definitely just moves around the buckets:

https://github.com/dlang/druntime/blob/20963f956c550b7b1b52849e5cf41f436d0df788/src/rt/aaA.d#L144-L157

That free at the end is just for the original Bucket[] array.

A Bucket is just a hash and a void pointer to the actual key/value pair. When you get a pointer to an AA value, it's to the key/value pair block (there is no struct for this, it's done via runtime type information, which is horrific legacy).

-Steve