www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - OT: WWDC 2021, ARC in Swift: Basics and beyond

reply Paulo Pinto <pjmlp progtools.org> writes:
This year's WWDC 2021 session on ARC optimization was focused on 
handling lifetime bugs caused by misuse of weak and owned 
references, alongside compiler optimizations that ellide 
retain/release calls.

https://developer.apple.com/videos/play/wwdc2021/10216/

Maybe consider if this is the future the anti-GC folks want to 
have in D.

It is nice to throw ARC around when unaware of the details how it 
actually works, possible bugs or crashes.
Jun 12
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 12 June 2021 at 11:44:11 UTC, Paulo Pinto wrote:
 It is nice to throw ARC around when unaware of the details how 
 it actually works, possible bugs or crashes.
D is a system level language where the default pointer cast is equivalent to C++ reinterpret_cast. D is not a higher level language like Swift. I think most D programmers have no problem using good old reference counting. Understanding how to use weak references is a pretty insignificant issue compared to all the other things that can go wrong when using a system level language like D.
Jun 12
parent reply IGotD- <nise nise.com> writes:
On Saturday, 12 June 2021 at 11:56:45 UTC, Ola Fosheim Grøstad 
wrote:
 D is a system level language where the default pointer cast is 
 equivalent to C++ reinterpret_cast. D is not a higher level 
 language like Swift.

 I think most D programmers have no problem using good old 
 reference counting. Understanding how to use weak references is 
 a pretty insignificant issue compared to all the other things 
 that can go wrong when using a system level language like D.
Nim doesn't use weak references but has cyclic reference detection instead. https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc-in-nim.html One of the strengths of Nim is that you can just plug and play a different GC and this also means badging the code with weak references doesn't play well with that versatility. Also, weak references means that we now have manual memory management again and if not used properly then the program will leak memory. Automatic memory management is no longer automatic with weak pointers. If D is going to implement ARC, then I suggest as automatic as possible with cycle detection.
Jun 12
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 12 June 2021 at 16:56:54 UTC, IGotD- wrote:
 Also, weak references means that we now have manual memory 
 management again and if not used properly then the program will 
 leak memory. Automatic memory management is no longer automatic 
 with weak pointers.
All programmers should create a model before they program. You only need to use weak-references if you pull down a datastructure in a disorderly fashion.
 If D is going to implement ARC, then I suggest as automatic as 
 possible with cycle detection.
Which basically is combining RC and tracing GC like Python. Then you might as well just use GC.
Jun 12
parent reply Elronnd <elronnd elronnd.net> writes:
On Saturday, 12 June 2021 at 17:55:46 UTC, Ola Fosheim Grøstad 
wrote:
 On Saturday, 12 June 2021 at 16:56:54 UTC, IGotD- wrote:
 If D is going to implement ARC, then I suggest as automatic as 
 possible with cycle detection.
Which basically is combining RC and tracing GC like Python. Then you might as well just use GC.
The advantage of reference counting is that it provides reliable gc pauses. How much of a difference that makes—particularly insofar as you can avoid allocations or disable collections during critical paths—is not clear, but it's certainly not so simple a calculus as you make it sound.
Jun 12
parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Sunday, 13 June 2021 at 00:50:44 UTC, Elronnd wrote:
 The advantage of reference counting is that it provides 
 reliable gc pauses.

 How much of a difference that makes—particularly insofar as you 
 can avoid allocations or disable collections during critical 
 paths—is not clear, but it's certainly not so simple a calculus 
 as you make it sound.
The point is that if you retain GC you still get the pausing of all threads. You still get bad destruction and unreliable destruction. And since you still dont have precise collection a big cycle will still leak. And it still is inappropriate for low mem devices. So you basically retain many of the bad properties of the current GC. It just dont happens as frequently. But by all means, I am not against people having the option, but it should not be the system level programming solution.
Jun 12
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 12 June 2021 at 16:56:54 UTC, IGotD- wrote:
 management again and if not used properly then the program will 
 leak memory. Automatic memory management is no longer automatic
Leaks will usually be detected during testing. Just make the runtime such that it tells you where the memory was allocated that wasn't freed when the program terminates. It isn't really all that complicated.
Jun 12
prev sibling parent sighoya <sighoya gmail.com> writes:
On Saturday, 12 June 2021 at 11:44:11 UTC, Paulo Pinto wrote:
 https://developer.apple.com/videos/play/wwdc2021/10216/

 Maybe consider if this is the future the anti-GC folks want to 
 have in D.

 It is nice to throw ARC around when unaware of the details how 
 it actually works, possible bugs or crashes.
Interesting, but it doesn't really apply to D as we only use shared reference counting as library feature, so we probably won't profit of such optimizations. However, I would favor the route the nim language does take and annotate certain parts of GC code as acyclic either proved or assumed, so these GC pointers can be excluded from cycle detection.
Jun 12