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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021