www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - UDA and trait for non-GC managed pointers

reply =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
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?
Oct 15 2016
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Oct 15 2016
parent reply =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
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.
Oct 15 2016
next sibling parent =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
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
Oct 15 2016
prev sibling parent ag0aep6g <anonymous example.com> writes:
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.
Oct 15 2016
prev sibling next sibling parent reply Basile B. <b2.temp gmx.com> writes:
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).
Oct 15 2016
next sibling parent reply =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
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.
Oct 15 2016
parent reply Basile B. <b2.temp gmx.com> writes:
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)...
Oct 15 2016
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 10/15/2016 02:50 PM, Basile B. wrote:

 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.


Mere weeks? Try over a year:
https://github.com/dlang/dmd/pull/4745
Oct 16 2016
prev sibling parent reply =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
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`?
Oct 15 2016
parent Basile B. <b2.temp gmx.com> writes:
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.
Oct 15 2016
prev sibling parent reply Chris Wright <dhasenan gmail.com> writes:
On Sat, 15 Oct 2016 16:22:35 +0000, Nordlöw wrote:


 Is there a way to check if a pointer is supposed to point to non-GC
 allocated memory?


You can check if it *does* point to GC-allocated memory if you use GC 
internals -- the Pool struct is what you want to look at, and the lookup 
methods associated with it.
Oct 15 2016
parent =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Sunday, 16 October 2016 at 04:14:42 UTC, Chris Wright wrote:

 On Sat, 15 Oct 2016 16:22:35 +0000, Nordlöw wrote:


 Is there a way to check if a pointer is supposed to point to 
 non-GC allocated memory?


 You can check if it *does* point to GC-allocated memory if you 
 use GC internals -- the Pool struct is what you want to look 
 at, and the lookup methods associated with it.


That's in run-time, though. I want it in compile-time so we can 
optimize away calls to GC.{add,Remove}Range. And that we don't 
have yet.

Thanks anyway.
Oct 16 2016