Is there a way to check if a pointer is supposed to point to non-GC allocated memory? I presume not. This is needed to prevent unnecessary calls to `GC.addRange` in containers with elements of a type that in turn is a container-like struct with non-GC allocated memory.

If not, maybe we could tag those non-GC-mangaged pointers with a UDA, preferrably `@nogc`, and then build a trait, say, `hasGCIndirections` that doesn't include @nogc-pointers.

What do you think?

On 10/15/2016 12:22 PM, Nordlöw wrote:
> Is there a way to check if a pointer is supposed to point to non-GC
> allocated memory? I presume not. This is needed to prevent unnecessary
> calls to `GC.addRange` in containers with elements of a type that in
> turn is a container-like struct with non-GC allocated memory.

I don't know of a simple way.

> If not, maybe we could tag those non-GC-mangaged pointers with a UDA,
> preferrably `@nogc`, and then build a trait, say, `hasGCIndirections`
> that doesn't include @nogc-pointers.
>
> What do you think?

Seems there'd be quite some annotational overhead. Some experience would be welcome.


Andrei

On Saturday, 15 October 2016 at 17:11:28 UTC, Andrei Alexandrescu wrote:
> Seems there'd be quite some annotational overhead.

In the case of a C++-style vector it's just a matter of changing

    E* _ptr;                // non-GC-allocated store pointer

to

    @nogc E* _ptr;          // GC-allocated store pointer

and then updating the relevant trait, such as `hasIndirections` or/and `hasAliasing`, to respect this attribute.

That doesn't seem to hard, right? Or am I missing something?

BTW: Should I use

https://dlang.org/phobos/std_traits.html#hasIndirections

or

https://dlang.org/phobos/std_traits.html#hasAliasing

ẁhen checking if I need to call `GC.addRange` and `GC.removeRange`?

The difference is whether we should include immutable indirections or not.

On Saturday, 15 October 2016 at 17:19:53 UTC, Nordlöw wrote:
>     E* _ptr;                // non-GC-allocated store pointer
>
> to
>
>     @nogc E* _ptr;          // GC-allocated store pointer

should, of course, be

>     E* _ptr;                // GC-allocated store pointer
>
> to
>
>     @nogc E* _ptr;          // non-GC-allocated store pointer

On 10/15/2016 07:19 PM, Nordlöw wrote:
> and then updating the relevant trait, such as `hasIndirections` or/and
> `hasAliasing`, to respect this attribute.

How would those traits have to updated? An indirection is an indirection no matter if it points to GC memory or not. Maybe we'd need a new trait.

[...]
> BTW: Should I use
>
> https://dlang.org/phobos/std_traits.html#hasIndirections
>
> or
>
> https://dlang.org/phobos/std_traits.html#hasAliasing
>
> ẁhen checking if I need to call `GC.addRange` and `GC.removeRange`?
>
> The difference is whether we should include immutable indirections or not.

As far as I see, hasIndirections. Immutable data needs to be collected, too.

On Saturday, 15 October 2016 at 16:22:35 UTC, Nordlöw wrote:
> Is there a way to check if a pointer is supposed to point to non-GC allocated memory? I presume not. This is needed to prevent unnecessary calls to `GC.addRange` in containers with elements of a type that in turn is a container-like struct with non-GC allocated memory.
>
> If not, maybe we could tag those non-GC-mangaged pointers with a UDA, preferrably `@nogc`, and then build a trait, say, `hasGCIndirections` that doesn't include @nogc-pointers.
>
> What do you think?

I agree. We are several people to do it already. I've started to during last spring (see https://forum.dlang.org/post/ficbsdfokvbvslatmomr@forum.dlang.org).
So far I use "@NoGc" and "@TellGcRange" added.

"@NoGc" is like what you describe, but it also allows to annotate class instances and, very important: D builtin array !

"@TellGcRange" prints a diagnostic at compile time which allows to find which aggregate members force my equivalent of "make" (called "construct") to declare a GC range (it should even be a root actually...).

To be honest I find this system way more useful that the function attribute @nogc.
My trait is here (https://github.com/BBasile/iz/blob/master/import/iz/memory.d#L145) but it's quite similar to the one used in EMSI containers (with diagnostic added).

On Saturday, 15 October 2016 at 17:48:13 UTC, Basile B. wrote:
> To be honest I find this system way more useful that the function attribute @nogc.
> My trait is here (https://github.com/BBasile/iz/blob/master/import/iz/memory.d#L145) but it's quite similar to the one used in EMSI containers (with diagnostic added).

Ok, great! I'll use your solution for now in phobos-next.

BTW: I took a look at `iz`. Loads of nice stuff, there! You and I have some serious work integrating all our D snippets into Phobos! Thanks.

On Saturday, 15 October 2016 at 18:03:54 UTC, Nordlöw wrote:
> On Saturday, 15 October 2016 at 17:48:13 UTC, Basile B. wrote:
>> To be honest I find this system way more useful that the function attribute @nogc.
>> My trait is here (https://github.com/BBasile/iz/blob/master/import/iz/memory.d#L145) but it's quite similar to the one used in EMSI containers (with diagnostic added).
>
> Ok, great! I'll use your solution for now in phobos-next.
>
> BTW: I took a look at `iz`. Loads of nice stuff, there! You and I have some serious work integrating all our D snippets into Phobos! Thanks.

I've given up with the idea of proposing my stuff in phobos. About memory there would also have be:
- allocators-based factory (https://github.com/dlang/phobos/pull/4062)
- @nogc dispose (https://github.com/dlang/phobos/pull/4351)

But each time the PR was a failure. Since last spring I've stopped to think that my stuff would be useful and I hole up in my user library.

Even some simple bug fixes can be completely ignored during weeks, even if reviewed:
- https://github.com/dlang/phobos/pull/4439
- https://github.com/dlang/phobos/pull/4475
- https://github.com/dlang/phobos/pull/4296

After a while it becomes clears that it's a loss of time. What's a definition of madness already ? Trying always the same thing (here: make phobos PRs) and expecting a different result (here: being merged)...

On Saturday, 15 October 2016 at 17:48:13 UTC, Basile B. wrote:
> I agree. We are several people to do it already. I've started to during last spring (see https://forum.dlang.org/post/ficbsdfokvbvslatmomr@forum.dlang.org).
> So far I use "@NoGc" and "@TellGcRange" added.

Why does the template argument to `MustAddGcRange` default to `void`?

And why can't `MustAddGcRange` just be called any type instead of just `struct`, `union` or `class`?

On Saturday, 15 October 2016 at 19:36:19 UTC, Nordlöw wrote:
> On Saturday, 15 October 2016 at 17:48:13 UTC, Basile B. wrote:
>> I agree. We are several people to do it already. I've started to during last spring (see https://forum.dlang.org/post/ficbsdfokvbvslatmomr@forum.dlang.org).
>> So far I use "@NoGc" and "@TellGcRange" added.
>
> Why does the template argument to `MustAddGcRange` default to `void`?

It's probably something that I've forget to remove. Maybe it's been added for debugging purpose. It's clearly not needed and the unittests pass without.

> And why can't `MustAddGcRange` just be called any type instead of just `struct`, `union` or `class`?

Because MustAddGcRange is used in "construct" which only handles structs, unions or classes.