www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Precise GC state

reply Temtaime <temtaime gmail.com> writes:
Hi all !
https://github.com/dlang/druntime/pull/1603

Can someone investigate and bring it to us ?
4 years passed from gsoc 2013 and there's still no gc.
Many apps suffers from false pointers and bringing such a gc will 
help those who affected by it.
It seems all the tests are passed except win32 because of optlink 
failures.
Maybe there's some chance to accelerate this PR ?

Thanks all
Nov 22
next sibling parent Adam Wilson <flyboynw gmail.com> writes:
On 11/22/17 02:53, Temtaime wrote:
 Hi all !
 https://github.com/dlang/druntime/pull/1603

 Can someone investigate and bring it to us ?
 4 years passed from gsoc 2013 and there's still no gc.
 Many apps suffers from false pointers and bringing such a gc will help
 those who affected by it.
 It seems all the tests are passed except win32 because of optlink failures.
 Maybe there's some chance to accelerate this PR ?

 Thanks all
+1 -- Adam Wilson IRC: LightBender import quiet.dlang.dev;
Nov 22
prev sibling parent reply =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Wednesday, 22 November 2017 at 10:53:45 UTC, Temtaime wrote:
 Hi all !
 https://github.com/dlang/druntime/pull/1603
Only the Win32 build fails as Error: more than 32767 symbols in object file What's wrong?
Nov 22
parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Wednesday, 22 November 2017 at 13:23:54 UTC, Nordlöw wrote:
 On Wednesday, 22 November 2017 at 10:53:45 UTC, Temtaime wrote:
 Hi all !
 https://github.com/dlang/druntime/pull/1603
Only the Win32 build fails as Error: more than 32767 symbols in object file What's wrong?
Thats a linker(?) limitation for OMF (or whatever is the win32 object file format).
Nov 22
next sibling parent Adam Wilson <flyboynw gmail.com> writes:
On 11/22/17 05:44, Nicholas Wilson wrote:
 On Wednesday, 22 November 2017 at 13:23:54 UTC, Nordlöw wrote:
 On Wednesday, 22 November 2017 at 10:53:45 UTC, Temtaime wrote:
 Hi all !
 https://github.com/dlang/druntime/pull/1603
Only the Win32 build fails as Error: more than 32767 symbols in object file What's wrong?
Thats a linker(?) limitation for OMF (or whatever is the win32 object file format).
We really should be using the MSVC linker on Windows for both x86 and x64. I propose we change the default behavior of -m32 to point to MSVC, keep the -m32mscoff, but mark it as deprecated, and add a -m32omf flag to retain the current behavior. -- Adam Wilson IRC: LightBender import quiet.dlang.dev;
Nov 22
prev sibling parent reply =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Wednesday, 22 November 2017 at 13:44:22 UTC, Nicholas Wilson 
wrote:
 Thats a linker(?) limitation for OMF (or whatever is the win32 
 object file format).
Was just fixed! What improvements to D's concurrency model is made possible with this precise GC? I recall Martin Nowak saying at DConf 2016 that a precise GC will enable data with isolated or immutable indirections to be safely moved between threads
Nov 23
parent reply Adam Wilson <flyboynw gmail.com> writes:
On 11/23/17 02:47, Nordlöw wrote:
 On Wednesday, 22 November 2017 at 13:44:22 UTC, Nicholas Wilson wrote:
 Thats a linker(?) limitation for OMF (or whatever is the win32 object
 file format).
Was just fixed! What improvements to D's concurrency model is made possible with this precise GC? I recall Martin Nowak saying at DConf 2016 that a precise GC will enable data with isolated or immutable indirections to be safely moved between threads
Rainer is awesome! That is certainly one aspect that it will enable. I would focus on a generational GC first for two reasons. The first is that you can delay the scans of the later gens if the Gen0 (nursery) has enough space, so for a lot of programs it would result in a significant cut-down in collection times. The second is that you still typically have to stop the execution of the thread on the Gen0 collection (the objects most likely to be hot). So with a non-generational concurrent collector you have to stop the thread for the entirety of the scan, because you have no way to know which objects are hot and which are cold. -- Adam Wilson IRC: LightBender import quiet.dlang.dev;
Nov 23
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Thursday, 23 November 2017 at 20:13:31 UTC, Adam Wilson wrote:
 I would focus on a generational GC first for two reasons. The
But generational GC only makes sense if many of your GC objects have a short life span. I don't think this fits well with sensible use of a language like D where you typically would try to put such allocations on the stack and/or use RAII or even an arena.
 The second is that you still typically have to stop the 
 execution of the thread on the Gen0 collection (the objects 
 most likely to be hot). So with a non-generational concurrent 
 collector you have to stop the thread for the entirety of the 
 scan, because you have no way to know which objects are hot and 
 which are cold.
How are you going to prove that references are all kept within the generation in D? There is some very costly book keeping involved that simply don't work well with D semantics.
Nov 23
parent reply Adam Wilson <flyboynw gmail.com> writes:
On 11/23/17 13:40, Ola Fosheim Grøstad wrote:
 On Thursday, 23 November 2017 at 20:13:31 UTC, Adam Wilson wrote:
 I would focus on a generational GC first for two reasons. The
But generational GC only makes sense if many of your GC objects have a short life span. I don't think this fits well with sensible use of a language like D where you typically would try to put such allocations on the stack and/or use RAII or even an arena.
Sensible to whom? The great thing about D is that it works just we well for low-level people who need to wring the most out of the metal, AND the high-level productivity minded apps people, who don't. RAII+stack allocations make sense when I care about WHEN an object is released and wish to provide some semblance of control over deallocation (although as Andrei has pointed out numerous time, you have no idea how many objects are hiding under that RAII pointer). But there are plenty of use cases where I really don't care when memory is released, or even how long it takes to release. For example, all of the D apps that I've written and use in production, GC-allocate everything. I don't have a single struct in the code. But I don't care, because the program is so short lived and the working set so small that there will never be GC collection. And it's not like this is an uncommon or unwise pattern in D, DMD itself follows this exact pattern. Obviously my pattern isn't "wrong" or else DMD itself is "wrong". It's just not your definition of "correct". Another use case where RAII makes no sense is GUI apps. The object graph required to maintain the state of all those widgets can be an absolute performance nightmare on destruction. Closing a window can result in the destruction of tens-of-thousands of objects (I've worked on codebases like that), all from the GUI thread, causing a hang, and a bad user experience. Or you could use a concurrent GC and pass off the collection to a different thread. (See .NET)
 The second is that you still typically have to stop the execution of
 the thread on the Gen0 collection (the objects most likely to be hot).
 So with a non-generational concurrent collector you have to stop the
 thread for the entirety of the scan, because you have no way to know
 which objects are hot and which are cold.
How are you going to prove that references are all kept within the generation in D? There is some very costly book keeping involved that simply don't work well with D semantics.
Again, which semantics? If you compile with -betterc, the bookkeeping and it's overhead simply don't exist. Your arguments are based on a presupposition that D should only be used a certain way; a way that, I am sure, mirrors your own usage patterns. D supports a multitude of different usage patterns, some of which look nothing like what you are holding up as "correct". And this is what makes D special. To remove or dismiss as invalid those usage patterns would be detrimental to those of us who use them and be catastrophic to D in general. As a community, can we please stop it with the subjective judgements of what is and is not "sensible" in D, and start supporting the people using it, however they are using it, even if we are sure that they are "wrong"? -- Adam Wilson IRC: LightBender import quiet.dlang.dev;
Nov 23
next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On Friday, 24 November 2017 at 05:34:14 UTC, Adam Wilson wrote:
 On 11/23/17 13:40, Ola Fosheim Grøstad wrote:
 On Thursday, 23 November 2017 at 20:13:31 UTC, Adam Wilson 
 wrote:
 I would focus on a generational GC first for two reasons. The
But generational GC only makes sense if many of your GC objects have a short life span. I don't think this fits well with sensible use of a language like D where you typically would try to put such allocations on the stack and/or use RAII or even an arena.
Sensible to whom? The great thing about D is that it works just we well for low-level people who need to wring the most out of the metal, AND the high-level productivity minded apps people, who don't.
The problem with generational GC is “write barriers” - pieces of code compiler needs to insert around every write of a pointer. Now given that we can cast pointer to integer and back (also unions), I don’t see how it would work unless we put write barriers everywhere on the off-chance it did wrote a pointer from OLD to NEW space. A better GC is a great direction. Generational one is not feasible unless we disallow quite a few of our features.
Nov 23
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Friday, 24 November 2017 at 05:53:37 UTC, Dmitry Olshansky 
wrote:
 A better GC is a great direction. Generational one is not 
 feasible unless we disallow quite a few of our features.
What about safe?
Nov 25
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On Sunday, 26 November 2017 at 04:01:31 UTC, jmh530 wrote:
 On Friday, 24 November 2017 at 05:53:37 UTC, Dmitry Olshansky 
 wrote:
 A better GC is a great direction. Generational one is not 
 feasible unless we disallow quite a few of our features.
What about safe?
If all of the code is 100% safe (not system and not trusted) you have a different language where write barriers would be cheaper to implement. Sadly you can’t “skip” write barriers in your system code because it may run as part of larger safe. Which is where they are the most costly.
Nov 26
next sibling parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Sunday, 26 November 2017 at 08:49:42 UTC, Dmitry Olshansky 
wrote:
 Sadly you can’t “skip” write barriers in your  system code 
 because it may run as part of larger  safe. Which is where they
Well, you can if you carefully lock the gc runtime or if you dont modify existing scannable pointers that points to existing objects (e.g. You could fill an empty array of pointers in unsafe code or pointers that point to something unscannable.), but all unsafe code would need vetting. So it isnt impossible technically, but it is impossible without a change of philosophy.
Nov 26
prev sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Sunday, 26 November 2017 at 08:49:42 UTC, Dmitry Olshansky 
wrote:
 If all of the code is 100%  safe (not system and not trusted) 
 you have a different language where write barriers would be 
 cheaper to implement.

 Sadly you can’t “skip” write barriers in your  system code 
 because it may run as part of larger  safe. Which is where they 
 are the most costly.
I was thinking you would use a generational or precise GC for safe code and then fall back to the normal GC with system/ trusted code. Not sure if that's possible or not, but in my head it would be a separate heap from the safe code. Certainly would be added complexity.
Nov 26
next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Sunday, November 26, 2017 18:58:04 jmh530 via Digitalmars-d wrote:
 On Sunday, 26 November 2017 at 08:49:42 UTC, Dmitry Olshansky

 wrote:
 If all of the code is 100%  safe (not system and not trusted)
 you have a different language where write barriers would be
 cheaper to implement.

 Sadly you can’t “skip” write barriers in your  system code
 because it may run as part of larger  safe. Which is where they
 are the most costly.
I was thinking you would use a generational or precise GC for safe code and then fall back to the normal GC with system/ trusted code. Not sure if that's possible or not, but in my head it would be a separate heap from the safe code. Certainly would be added complexity.
It wouldn't work. safe code and system code call each other all the time (using trusted where necessary), and they freely exchange stuff that was allocated on the GC heap. Heck, it's not even possible to have per-thread heaps (much as that would be desirable), because stuff can be passed between threads, and you can freely cast between shared and non-shared. You do have to be careful about it if you don't want to have problems, but just like safe code can call trusted code such that it's possible for safe code be calling code that was vetted for memory safety by a programmer rather than the compiler, you can have code that casts to and from shared and works perfectly well so long as the programmer vets it properly. We can't even have different heaps for immutable and mutable stuff, because it's very common to construct something as mutable and then cast it to immutable (either explicitly or because it's returned from a pure function which is able to do the cast implicitly, because it knows that the return value couldn't possibly have been passed into the function and thus had to have been allocated inside it). D's type system protects you from all kinds of dumb mistakes, but it has way too many backdoors for the kind of stuff that requires that things be locked down like they would be inside a VM like Java has. Ultimately, if you're talking about a GC and what it can and can't do, I expect that there's very little difference between C and D in terms of what you types of GC you can get away with. D does protect the programmer, but ultimately, it lets you do just about anything that C lets you do if you really want to, and any GC that we use has to work with that. - Jonathan M Davis
Nov 26
next sibling parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Sunday, 26 November 2017 at 19:11:08 UTC, Jonathan M Davis 
wrote:
 We can't even have different heaps for immutable and mutable 
 stuff, because it's very common to construct something as 
 mutable and then cast it to immutable (either explicitly or
This is easy to fix, introduce a uniquely owned type (isolated) that only can transition to immutable. So it is more about being willing to tighten up the semantics. Same thing with GC, but everything has a cost. That said Adam has a point with getting more users, it isnt obvious that the costs wouldnt be offset by increased interest. Anyway, it seems like C# and Swift are pursuing the domain D is in by gradually expanding into more performance oriented programming mechanisms... We'll see.
Nov 26
prev sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Sunday, 26 November 2017 at 19:11:08 UTC, Jonathan M Davis 
wrote:
 It wouldn't work.  safe code and  system code call each other 
 all the time (using  trusted where necessary), and they freely 
 exchange stuff that was allocated on the GC heap. [snip]
I see. Fair enough.
Nov 26
prev sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On Sunday, 26 November 2017 at 18:58:04 UTC, jmh530 wrote:
 On Sunday, 26 November 2017 at 08:49:42 UTC, Dmitry Olshansky 
 wrote:
 If all of the code is 100%  safe (not system and not trusted) 
 you have a different language where write barriers would be 
 cheaper to implement.

 Sadly you can’t “skip” write barriers in your  system code 
 because it may run as part of larger  safe. Which is where 
 they are the most costly.
I was thinking you would use a generational or precise GC for safe code and then fall back to the normal GC with system/ trusted code.
Wishful thinking. Memory flows through a program and things allocated in safe get passed to system (including the last reference cases) and vise versa. Also in D generational hypothesis may not bear as much value due to stack-allocation, libc heap allocations for temporaries likely via RAII. Not to mention cheap (thread-local) Ref Counting, C++ and many other language have to use atomics which makes RC costly. Basically the GC heap is not all of the heap, so a young objects is even smaller part of that. Lastly it is telling that new low-latency concurrent GCs do away without explicit generations. I’m thinking a more efficient way to takle temporaries would be to add Regions to GC. So the moment you enter a region all GC things are allocated in a special segment, once you leave it free the segment. The last trick is to tweak memory protection as guard pages over it. Boom! Now if somebody touches it - DanglingPointerException :) Not a panacea but: - libraries using too much of GC can be controlled (unless they build global state) - manual memory management without memory corruption - fast bump allocation, which is what all of sensible VM languages do And no need to create entire separate heap with its own generational schema.
 Not sure if that's possible or not, but in my head it would be 
 a separate heap from the  safe code.
And then I do append in system on array allocated in safe. Boom!
 Certainly would be added complexity.
Nov 26
parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Monday, 27 November 2017 at 05:47:49 UTC, Dmitry Olshansky 
wrote:
 likely via RAII. Not to mention cheap (thread-local) Ref 
 Counting, C++ and many other language have to use atomics which 
 makes RC costly.
No, you dont. Nobody in their right mind would do so in C++ as a general solution. Seems there is trend in doing D-advocacy based on the assumption that programmers using other languages are crazy these days. In C++ sync is manual, which is the only efficient way to do it. Proving correctness for an efficient general solution is an unsolved theoretical problem. You can do it for high level mechanisms, but not low level atm. Rust and Pony claims to have solutions, but they are not general. D most certainly does not have it and never will. When threading is a libray type then you cannot achieve more in D than you can achieve in C++, i.e. Shared is not going to do more than a C++ library type with a separate static analysis tool.
Nov 26
next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On Monday, 27 November 2017 at 06:36:27 UTC, Ola Fosheim Grostad 
wrote:
 On Monday, 27 November 2017 at 05:47:49 UTC, Dmitry Olshansky 
 wrote:
 likely via RAII. Not to mention cheap (thread-local) Ref 
 Counting, C++ and many other language have to use atomics 
 which makes RC costly.
No, you dont. Nobody in their right mind would do so in C++ as a general solution. Seems there is trend in doing D-advocacy based on the assumption that programmers using other languages are crazy these days.
Last time I check shared_ptr can be safely shared across threads, hence RC is takling synchronization and most likely atomics since locks won’t be any better.
 In C++ sync is manual, which is the only efficient way to do
??? shared_ptr is nowhere manual. Sorry but the rest of the of post is take a direction into the fog, that I don’t want to follow. My post is about particular primitive in C++ std, what could be done instead or in addition to is not important.
Nov 26
parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Monday, 27 November 2017 at 06:47:00 UTC, Dmitry Olshansky 
wrote:
 Last time I check shared_ptr can be safely shared across 
 threads, hence RC is takling synchronization and most likely 
 atomics since locks won’t be any better.
The controlblock can, but it is crazy to use shared_ptr for anything more than high level ownership. It is a general solution with weak pointers and extra indirection, not a typical RC implementation for datastructures.
 In C++ sync is manual, which is the only efficient way to do
??? shared_ptr is nowhere manual.
There is an upcoming atomic_shared_ptr, but it is not in the standard yet.
 My post is about particular primitive in C++ std, what could be 
 done instead or in addition to is not important.
Oh, but it is. 1. D currently does not provide what you says it does. 2. Sane C++ programmers rarely use shared_ptr for more than exchsnging ownership (suitable for sharing things like bitmap textures). There are plenty of other RC implementations for tracking memory. So you compare apples and oranges.
Nov 26
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On Monday, 27 November 2017 at 07:03:01 UTC, Ola Fosheim Grostad 
wrote:
 On Monday, 27 November 2017 at 06:47:00 UTC, Dmitry Olshansky 
 wrote:
 Last time I check shared_ptr can be safely shared across 
 threads, hence RC is takling synchronization and most likely 
 atomics since locks won’t be any better.
The controlblock can, but it is crazy to use shared_ptr for anything more than high level ownership. It is a general solution with weak pointers and extra indirection, not a typical RC implementation for datastructures.
Then watch Herb’s Sutter recent talk “Leak freedom by default”. Now THAT guy must be out of his mind :) I have no idea what are your typical C++ programmers.
 In C++ sync is manual, which is the only efficient way to do
??? shared_ptr is nowhere manual.
There is an upcoming atomic_shared_ptr, but it is not in the standard yet.
atomic_shared_pointer is nothing but what you seem to imply. It’s not manual sync for one.
 My post is about particular primitive in C++ std, what could 
 be done instead or in addition to is not important.
Oh, but it is.
You keep spreading FUD on this forum, I’m still not sure of your reasons though.
 1. D currently does not provide what you says it does.
RefCounted!T
 2. Sane C++ programmers rarely use shared_ptr for more than 
 exchsnging ownership (suitable for sharing things like bitmap 
 textures).
Including across threads btw.
 There are plenty of other RC implementations for tracking 
 memory.
Like what? In standard C++ all you’ve got is unique_ptr and shared_ptr (and weak but that besides the point). There is maybe a ton of reimplementations of said things.
Nov 27
parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Monday, 27 November 2017 at 14:35:03 UTC, Dmitry Olshansky 
wrote:
 Then watch Herb’s Sutter recent talk “Leak freedom by default”. 
 Now THAT guy must be out of his mind :)
He could be, I havent seen it... Shared_ptr isnt frequently used, it is a last resort,
 atomic_shared_pointer is nothing but what you seem to imply. 
 It’s not manual sync for one.
Err... That was my point... Only assignment and reset is protected in shared_ptr, all other methods require manual sync.
 You keep spreading FUD on this forum, I’m still not sure of 
 your reasons though.
And there we go ad hominem as usual... With no argument to back it up... Bye.
Nov 27
next sibling parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
Btw, it would improve the discourse if people tried to 
distinguish between language constructs and library constructs...
Nov 27
prev sibling next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On Monday, 27 November 2017 at 15:56:09 UTC, Ola Fosheim Grostad 
wrote:
 On Monday, 27 November 2017 at 14:35:03 UTC, Dmitry Olshansky 
 wrote:
 Then watch Herb’s Sutter recent talk “Leak freedom by 
 default”. Now THAT guy must be out of his mind :)
He could be, I havent seen it... Shared_ptr isnt frequently used, it is a last resort,
Ahhhaaahhha. Really, shared_ptr is the most contagious primitive of modern C++. To quote MS STL guy “I’m surprised we had no non-inteusive ref-counted ptr in std lib for so long”. Going Native videos are full of questions on that.
 atomic_shared_pointer is nothing but what you seem to imply. 
 It’s not manual sync for one.
Err... That was my point... Only assignment and reset is protected in shared_ptr, all other methods require manual sync.
For the benefit of others, let me destroy that: - shared_ptr allows to share T with thread-safe ownership, ref-counts are accounted atomically (sharing copies of shared_ptr pointing to the same block). Copy of shared_ptr is thread safe and does the count. - atomic_shared_prt would also allow one to initialize a shared variable (eg global) of type shared_ptr safely from multiple threads The manual synchronization part comes in if you try to work with payload T itself. THAT is manual. Since C++ doesn’t see a difference at type level of shared vs local, there is no thread-local variation of shared_ptr. It would be too unsafe even for those guys, contrary to what Ola responses imply.
 You keep spreading FUD on this forum, I’m still not sure of 
 your reasons though.
And there we go ad hominem as usual... With no argument to back it up... Bye.
Well I can clearly see misinformation and describe it as such. See your point about atomic_shared_ptr.
Nov 27
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 27 November 2017 at 17:16:50 UTC, Dmitry Olshansky 
wrote:
 Really, shared_ptr is the most contagious primitive of modern 
 C++.
Not really. Unique_ptr is, though.
 To quote MS STL guy “I’m surprised we had no non-inteusive 
 ref-counted ptr in std lib for so long”.
 Going Native videos are full of questions on that.
Yeah, they tend to pretend that C++ is a high level language, it makes for good talks. Let me put it this way, C++ is an acceptable low level language, but it is a rather poor high level language. So if you talk with people who use C++ as a high level language you probably see different usage patterns.
 Err... That was my point... Only assignment and reset is 
 protected in shared_ptr, all other methods require manual sync.
For the benefit of others, let me destroy that:
Oh well, looks like reset and assignment isn't required per the spec to be protected against races either. That doesn't weaken my point, the control block is protected but not the methods of shared_ptr. I hardly ever use shared_ptr. In practical programming you usually need to exchange more than a single entity so you need manual sync anyway.
 - shared_ptr allows to share T with thread-safe ownership, 
 ref-counts are accounted atomically (sharing copies of 
 shared_ptr pointing to the same block). Copy of shared_ptr is 
 thread safe and does the count.
Not sure if I follow that description. Shared shared_ptr's are not thread safe, a shared control block is. (Technically you share a pointer, not an object of type T, but that is a minor detail.) shared_ptr is pointing to a shared control block that in turn has a pointer that points to the resource. This control block contains two counters. These counters are incremented and decremented atomically. If you access the same shared_ptr from two threads then you have a potential race condition per the spec.
 - atomic_shared_prt would also allow one to initialize a shared 
 variable (eg global) of type shared_ptr safely from multiple 
 threads
The main point is that the methods of atomic_shared_ptr are protected against races. It is needed because you usually would have have ownership pointers embedded in a another shared object. So having a protected control-block is not sufficient outside the trivial toy-program.
 The manual synchronization part comes in if you try to work 
 with payload T itself. THAT is manual.
No, none of the methods on shared_ptr guarantees that races won't happen. And in general you usually want to access more than one unit in a critical section. So in C++ you typically need manual sync. There are no suitable language features to get around that in C++ and library features are inadequate in the general sense. Go and Pony have language features that are helpful. C++ doesn't.
 Since C++ doesn’t see a difference at type level of shared vs 
 local, there is no thread-local variation of shared_ptr. It 
 would be too unsafe even for those guys, contrary to what Ola 
 responses imply.
Sigh. I implied that shared_ptr on a single thread is mostly useless. But this: struct OurSharedCache { shared_ptr<T> something; shared_ptr<T> somethingelse } Not safe.
 Well I can clearly see misinformation and describe it as such. 
 See your point about atomic_shared_ptr.
What about it? «If multiple threads of execution access the same shared_ptr without synchronization and any of those accesses uses a non-const member function of shared_ptr then a data race will occur» http://en.cppreference.com/w/cpp/memory/shared_ptr «The class template atomic_shared_ptr provides thread-safe atomic pointer operations over a std::shared_ptr.» http://en.cppreference.com/w/cpp/experimental/atomic_shared_ptr
Nov 27
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On Monday, 27 November 2017 at 18:29:56 UTC, Ola Fosheim Grøstad 
wrote:
 On Monday, 27 November 2017 at 17:16:50 UTC, Dmitry Olshansky 
 wrote:
 Really, shared_ptr is the most contagious primitive of modern 
 C++.
Not really. Unique_ptr is, though.
 To quote MS STL guy “I’m surprised we had no non-inteusive 
 ref-counted ptr in std lib for so long”.
 Going Native videos are full of questions on that.
Yeah, they tend to pretend that C++ is a high level language, it makes for good talks. Let me put it this way, C++ is an acceptable low level language, but it is a rather poor high level language. So if you talk with people who use C++ as a high level language you probably see different usage patterns.
I’ve seen a tech giant that works on uber high-performance things making heavy use of STL, and being fond of C++14 “high-level” features. I almost took their job offer, it is a nice place. Comparatively I’ve worked at Google where none of the new goodies are in use. There are some great things in their “std”, but most have horrible interfaces and people routinelly discuss how having at least STL-like primitives would be a huge boon.
 Err... That was my point... Only assignment and reset is 
 protected in shared_ptr, all other methods require manual 
 sync.
For the benefit of others, let me destroy that:
Oh well, looks like reset and assignment isn't required per the spec to be protected against races either. That doesn't weaken my point, the control block is protected but not the methods of shared_ptr. I hardly ever use shared_ptr. In practical programming you
That must be why you seriously have no idea how people use it. Otherwise you’d know that nobody shares a reference to shared pointer but rather a copy. The whole point of smart pointer is to avoid naked references.
 - shared_ptr allows to share T with thread-safe ownership, 
 ref-counts are accounted atomically (sharing copies of 
 shared_ptr pointing to the same block). Copy of shared_ptr is 
 thread safe and does the count.
Not sure if I follow that description. Shared shared_ptr's are not thread safe
They are if you use them as intended - value types, that pretend to be pointers.
 a shared control block is. (Technically you share a pointer, 
 not an object of type T, but that is a minor detail.)
No, you actually share an object and the last one to decrement the ref will destroy it. Now that is actually thread-safe thanks to atomic counter.
 shared_ptr is pointing to a shared control block that in turn 
 has a pointer that points to the resource. This control block  
 contains two counters. These counters are incremented and 
 decremented atomically.
That is my original point, which you now violently agree with :)
 If you access the same shared_ptr from two threads then you 
 have a potential race condition per the spec.
Just underlines that you don’t understand how it is supposed to be used.
 - atomic_shared_prt would also allow one to initialize a 
 shared variable (eg global) of type shared_ptr safely from 
 multiple threads
The main point is that the methods of atomic_shared_ptr are protected against races. It is needed because you usually would have have ownership pointers embedded in a another shared object. So having a protected control-block is not sufficient outside the trivial toy-program.
Sufficient for what? Smart pointers are about ownership not protecting from races. I also don’t understand what are you trying to prove. My point was: C++ has to do atomic counting, because it has no concept of shared vs local. All of things you’ve said just prove it or are talking about something I’m not discussing here.
 The manual synchronization part comes in if you try to work 
 with payload T itself. THAT is manual.
No, none of the methods on shared_ptr guarantees that races won't happen.
Just as you quoted below - all const are, including copy & destructor.
 Since C++ doesn’t see a difference at type level of shared vs 
 local, there is no thread-local variation of shared_ptr. It 
 would be too unsafe even for those guys, contrary to what Ola 
 responses imply.
Sigh. I implied that shared_ptr on a single thread is mostly useless.
You did imply it’s useless on single thread and not used in concurrency because you need manual sync. I’d argue you don’t need a sync to access shared_ptr, you’d need it for object it points to. It still solves the ownership and deterministic destruction in the presense of concurrent shared_ptrs of the same object. But again - you countered a different point all together, see above.
 But this:

 struct OurSharedCache {
    shared_ptr<T> something;
    shared_ptr<T> somethingelse
 }
Not that I talked about it. This has nothing to do with shared_ptr and/or things I stated originally.
 Well I can clearly see misinformation and describe it as such. 
 See your point about atomic_shared_ptr.
What about it? «If multiple threads of execution access the same shared_ptr without synchronization and any of those accesses uses a non-const member function of shared_ptr then a data race will occur»
Copy & destruction is actually fine, which you seem to ignore. Also accessing const methods of payload is fine. New C++ implies const == thread safe btw, at least in all of STL.
Nov 27
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 27 November 2017 at 20:13:35 UTC, Dmitry Olshansky 
wrote:
 I’ve seen a tech giant that works on uber high-performance 
 things making heavy use of STL, and being fond of C++14 
 “high-level” features.
Look, I am not against "high level" features, but shared_ptr is nothing like the thread local ref-counting you were talking about which was at least introduced by Walter and Andrei as a competing solution to tracking of borrowed pointers in Rust.
 That must be why you seriously have no idea how people use it. 
 Otherwise you’d know that nobody shares a reference to shared 
 pointer but rather a copy. The whole point of smart pointer is 
 to avoid naked references.
I have an idea of how people use it… why all the ad hominem? I just don't find it very useful. In practice I'm usually better off exchanging through a facade and having the exchanged resource wrapped up in a custom type. It is more maintainable and easy to deal with in terms of correctness.
 They are if you use them as intended - value types, that 
 pretend to be pointers.
Sure. Not that this is how they are defined to be used. It is a very limited use case.
 a shared control block is. (Technically you share a pointer, 
 not an object of type T, but that is a minor detail.)
No, you actually share an object and the last one to decrement the ref will destroy it. Now that is actually thread-safe thanks to atomic counter.
Ok, sure, you share an ownership relation to an object, but it isn't general enough, which was what I tried to suggest. For instance, if you have a resource on a GPU with an integer ID that is also a resource, but shared_ptr does not work (unless you accept extra indirections). So, I'd rather see an owned<T>, which also can handle non-pointed-to-objects. Then one might ask, why not just have "unique<owningptr<T>>" or "shared<owningptr<T>>" that also would work with "unique<Resource>" and "shared<Resource>"? Then you can build generic ADTs with a generic notion of ownership . The basic idea is that an owned resource that has to go through a pointer isn't really necessary or as generic a type as it could have been.
 That is my original point, which you now violently agree with :)
Ok, then I didn't get your original point.
 Just underlines that you don’t understand how it is supposed to 
 be used.
I know how it can be used. That doesn't mean that it is as generally useful as it should be to be useful for what I want to do.
 I also don’t understand what are you trying to prove. My point 
 was: C++ has to do atomic counting, because it has no concept 
 of shared vs local.
That I disagree with. In C++ correct syncing is entirely dependent on the programmer. Even if atomic_shared_ptr provide some guarantees these guarantees will not hold if you depend on more than one entity. So there is no mechanism in C++ that provide something to ensure correctness when it comes to concurrency. I.e. you totally depend on the programmer's ability. You can create a concept of D-style local/shared by just creating a wrapper type and use a lint-style verification. This is the route C++ is heading in general for various properties related to pointer types it seems. (e.g. wrap with borrowed, owned, nullable etc). Which is also basically what D has, except shared is a builtin, but semantically I see no difference. To get a semantic difference that matter you need concurrency to be part of the language itself. If you cannot express propositions about concurrency in the language, then there is a very limited ability to do something interesting with it.
 You did imply it’s useless on single thread and not used in 
 concurrency because you need manual sync. I’d argue you don’t 
 need a sync to access shared_ptr, you’d need it for object it 
 points to.
Listen, if you build a shared graph with shared_ptrs then you are in trouble. So you would need atomic_shared_ptrs. That's a perfectly reasonable use case. You are presuming that the shared_ptr objects are thread local and that they are not embedded in other objects that are reachable by another thread. Those a very limiting presumptions.
 It still solves the ownership and deterministic destruction in 
 the presense of concurrent shared_ptrs of the same object.
But it doesn't solve correctness. You still rely on the programmer to get correctness. Which is a tall order when you use encapsulation. That only works if you never embed shared_ptr in a class.
 Copy & destruction is actually fine, which you seem to ignore. 
 Also accessing const methods of payload is fine. New C++ 
 implies const == thread safe btw, at least in all of STL.
As far as I can see from the description at cppreference.com there is no guarantee of freedom for races for anything if both threads reference the same shared_ptr object (not the control block but the object pointing to the control block). You can obviously transmit it to another thread using a mutex-like/messaging-like setup if that is what you mean.
Nov 27
prev sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Monday, November 27, 2017 15:56:09 Ola Fosheim Grostad via Digitalmars-d 
wrote:
 On Monday, 27 November 2017 at 14:35:03 UTC, Dmitry Olshansky

 wrote:
 Then watch Herb’s Sutter recent talk “Leak freedom by default”.
 Now THAT guy must be out of his mind :)
He could be, I havent seen it... Shared_ptr isnt frequently used, it is a last resort,
I don't understand this. I would expect most modern C++ programs to be using shared_ptr as the default for most pointers and thus use it heavily. Any time that I've been able to use at least TR1 for C++, I've used it everywhere, and when I've been stuck with C++98, I've used a home-grown equivalent. shared_ptr is a _huge_ boon for avoiding memory problems. - Jonathan M Davis
Nov 27
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 27 November 2017 at 18:00:59 UTC, Jonathan M Davis 
wrote:
 I don't understand this. I would expect most modern C++ 
 programs to be using shared_ptr as the default for most 
 pointers and thus use it heavily.
You get this: shared_ptr -> control_block -> object Instead of this: unique_ptr -> object my_ref_ptr ->object
 shared_ptr is a _huge_ boon for avoiding memory problems.
Yes, if you don't mind the inefficiency, i.e. if you are doing high-level programming in C++.
Nov 27
parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Monday, 27 November 2017 at 18:32:39 UTC, Ola Fosheim Grøstad 
wrote:
 You get this:

 shared_ptr -> control_block -> object
Actually, seems like the common implementation uses 16 bytes, so that it has a direct pointer as well. So twice the size of unique_ptr.
Nov 27
prev sibling parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Monday, 27 November 2017 at 06:36:27 UTC, Ola Fosheim Grostad 
wrote:
 On Monday, 27 November 2017 at 05:47:49 UTC, Dmitry Olshansky 
 wrote:
 likely via RAII. Not to mention cheap (thread-local) Ref 
 Counting, C++ and many other language have to use atomics 
 which makes RC costly.
No, you dont. Nobody in their right mind would do so in C++ as a general solution. Seems there is trend in doing D-advocacy based on the assumption that programmers using other languages are crazy these days. In C++ sync is manual, which is the only efficient way to do it. Proving correctness for an efficient general solution is an unsolved theoretical problem. You can do it for high level mechanisms, but not low level atm. Rust and Pony claims to have solutions, but they are not general. D most certainly does not have it and never will. When threading is a libray type then you cannot achieve more in D than you can achieve in C++, i.e. Shared is not going to do more than a C++ library type with a separate static analysis tool.
What I think Dmitry meant is that shared_ptr<T> uses atomic instructions for the reference counting (though you need to use atomic_shared_ptr, or atomic_* function if you want to modify the shared_ptr itself) and you can't opt out of that even if you're not sharing the shared_ptr with other threads. On the other hand in D, a properly designed SharedPtr(T) will use atomic instructions for reference counting, only if it's payload type T is has the 'shared' type qualifier. And if you have 'shared(SharedPtr(T))', only then you'll have atomic instructions for the SharedPtr struct itself, but unlike shared_ptr<T>, you won't have access to the non-thread safe methods.
Nov 26
parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Monday, 27 November 2017 at 06:59:30 UTC, Petar Kirov 
[ZombineDev] wrote:
 the shared_ptr itself) and you can't opt out of that even if 
 you're not sharing the shared_ptr with other threads.
Well, the compiler can in theory ellide atomics if it csn prove that the memory cannot be accessed by another thread. But it kinda is missing the point that if it only is in a single thread then it would typically only have only one assignment. Shared_ptr is for holding a resource not for using it...
Nov 26
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 27 November 2017 at 07:09:25 UTC, Ola Fosheim Grostad 
wrote:
 But it kinda is missing the point that if it only is in a 
 single thread then it would typically only have only one 
 assignment. Shared_ptr is for holding a resource not for using 
 it...
Just to expand a bit on this: What is lost here is that what has been proposed for D is to have a RC solution to solve what Rust does with borrowed pointers. Not unlike Swift. In C++ life time management of borrowed pointers is fully manual, so it relies on algorithmic design rather than a programming mechanism. Although for C++ there is upcoming wrapper-types to allow for separate static analysis tooling that is comparable to Rust. The intended usage is not comparable. (In C++ you typically will have per-type or per-application RC, wrapped up where you need it by encapsulation and move-semantics.)
Nov 27
parent reply Temtaime <temtaime gmail.com> writes:
Please stop this flame and make first real step into bringing 
precise GC to us.
Current GC in D is shit and all this speaking won't improve 
situation.
The PR is not merged although it passed all the tests.
Nov 27
next sibling parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Monday, 27 November 2017 at 09:38:52 UTC, Temtaime wrote:
 Please stop this flame
There is no flaming.
 Current GC in D is shit and all this speaking won't improve 
 situation.
If so, why are you here? But you are fundamentally wrong. Precise GC will not bring a general improvement, for that you need advanced pointer analysis. So you need a change of philosophy to get a performant GC: semantic changes.
Nov 27
prev sibling parent reply codephantom <me noyb.com> writes:
On Monday, 27 November 2017 at 09:38:52 UTC, Temtaime wrote:
 Current GC in D is shit
Can you elaborate? "D is totally useless"..."Dlang is a toy in outer space"... "GC in D is shit" .. I'm very open minded to these different argument styles, and occassionaly make use of them myself. But in a discussion about GC, some technical details might prove to be very useful to those of us following this discussion. I encourage you to further refine your argument... ;-) https://en.wikipedia.org/wiki/Argument
Nov 27
parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Monday, 27 November 2017 at 10:13:41 UTC, codephantom wrote:
 But in a discussion about GC, some technical details might 
 prove to be very useful to those of us following this 
 discussion.
Precise scanning of pointers makes sense when you have many cachelines on the GC with no pointers in them. But if you mostly have pointers (a large graph or a tree) then it makes little difference. You need to add a more extensive whole program type analysis where you prove that the GC memory heap isnt reachable from a type... I.e. "pointers reachable through class T can provably never point into the a GC heap in this specific program, so therefore we can ignore all pointers to T".
Nov 27
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 24 November 2017 at 05:34:14 UTC, Adam Wilson wrote:
 RAII+stack allocations make sense when I care about WHEN an 
 object is released and wish to provide some semblance of 
 control over deallocation (although as Andrei has pointed out 
 numerous time, you have no idea how many objects are hiding 
 under that RAII pointer). But there are plenty of use cases 
 where I really don't care when memory is released, or even how 
 long it takes to release.
A GC makes most sense when the compiler fail at disproving that an object can be part of cycle of references that can be detached. So it makes most sense for typically long lived objects. Imagine if you spend all the effort you would need to put into getting a generational GC to work well into implementing pointer analysis to improve automatic deallocation instead… In order to speed up generated code that allows a generational GC to run you still would need a massive amount of work put into pointer analysis + all the work of making a state of the art GC runtime. Most people consider designing and implementing pointer analysis to be difficult. The regular data flow analysis that the D compiler has now is trivial in comparison. Might need a new IR for it, not sure.
 Obviously my pattern isn't "wrong" or else DMD itself is 
 "wrong". It's just not your definition of "correct".
Well, you could redefine the semantics of D so that you disallow unsafe code and possibly some other things. Then maybe have generational GC would be easy to implement if you don't expect better performance than any other high level language.
 Another use case where RAII makes no sense is GUI apps. The 
 object graph required to maintain the state of all those 
 widgets can be an absolute performance nightmare on 
 destruction. Closing a window can result in the destruction of 
 tens-of-thousands of objects (I've worked on codebases like 
 that), all from the GUI thread, causing a hang, and a bad user 
 experience. Or you could use a concurrent GC and pass off the 
 collection to a different thread. (See .NET)
Sounds like someone didn't do design before the started coding and just kept adding stuff. Keep in mind that OS-X and iOS use reference counting for all objects and it seems to work for them. But they also have put a significant effort into pointer-analysis to reduce ref-count overhead, so still quite a lot more work for the compiler designer than plain RAII.
 Your arguments are based on a presupposition that D should only 
 be used a certain way;
No, it is based on what the D language semantics are and the stated philosophy and the required changes that it would involve. I have no problem with D switching to generational GC. Like you I think most programs can be made to work fine with the overhead, but then you would need to change the philosophy that Walter is following. You would also need to either invest a lot into pointer analysis to keep a clean separation between GC-references and non-GC references, or create a more unforgiving type system that ensure such separation. I think that having a generational GC (or other high level low-latency solutions) probably would be a good idea, but I don't see how anyone could convince Walter to change his mind on such issues. Especially as there are quite a few semantic flaws in D that would be easy to fix, that Walter will not fix because he like D as it is or thinks it would be too much of a breaking change. You would need to change the D philosophy from "performant with some convenience" to "convenience with some means to write performant code". I agree with you that the latter philosophy probably would attract more users. It is hard to compete with C++ and Rust on the former. But I am not sure if Walter's goal is to attract as many users as possible.
Nov 23
parent codephantom <me noyb.com> writes:
On Friday, 24 November 2017 at 07:48:03 UTC, Ola Fosheim Grøstad 
wrote:
 But I am not sure if Walter's goal is to attract as many users 
 as possible.
Given all the bullshit bugs I have to deal with, I'm starting to think it's the opposite.
Nov 24
prev sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On Thursday, 23 November 2017 at 20:13:31 UTC, Adam Wilson wrote:
 a precise GC will enable data with isolated or immutable 
 indirections to
 be safely moved between threads
I think you could in any case. What precise allows is to copy object during collection if there is no conservative pointers to the object, of course.
 I would focus on a generational GC first for two reasons. The 
 first is that you can delay the scans of the later gens if the 
 Gen0 (nursery) has enough space, so for a lot of programs it 
 would result in a significant cut-down in collection times.
This is like saying that having a large heap will allow you to cut-down collection time. The reason gen0 is fast is that it's mostly dead and you limit the amount of memory Gen0 scans to that of live set in Gen0 heap + remebered set in old gen. It has nothing to do with delaying the scan, in fact Gen0 scans are way more frequent then scans of a simple single-gen GC.
 The second is that you still typically have to stop the 
 execution of the thread on the Gen0 collection (the objects 
 most likely to be hot).
If your Gen0 collector is Stop the World, like all of Java collectors except for the most recent ones - ZGC and Shenandoah. Ironically both are not generational :)
 So with a non-generational concurrent collector you have to 
 stop the thread for the entirety of the scan,
False again. Any "mostly" concurrent GC can scan with a super small pause that is typically used only to mark stacks of Threads. See also the 2 collectors I mentioned. Go's GC is also non-generational (and SUUUPER popular) to put the last nail in the coffin of "I need generational GC because you can't do X without it?".
 because you have no way to know which objects are hot and which 
 are cold.
Why would that stop collector? There is no need to know what is hot, and garbage is always cold.
Nov 24