Directions for ARC Memory Management

[Marco Cantu 78]

Not sure this fits perfectly in this forum (more of a non-tech let's fight topic, 😉 ) but here it goes. I just blogged about the plans for 10.3 and beyond around ARC in Delphi.

See for more info http://blog.marcocantu.com/blog/2018-october-Delphi-ARC-directions.html

 

Honestly interested in feedback, suggestions and ideas. Less in "I told you" comments... 

[Lars Fosdal 1793]

From my perspective, I am very glad to see that the Linux compiler will use the same memory management model as the Windows compilers.  That makes it a lot easier for us to write cross-platform server code, something we have been pondering for a while.

[Markus Kinzler 174]

Perhaps an option would habe been better.

[Uwe Raabe 2063]

21 minutes ago, Markus Kinzler said:

Perhaps an option would habe been better.

An option for ARC/non-ARC would double the testing effort at least.

 

Given that over the years I learned how to mix objects and interfaces when necessary, I for myself feel quite comfortable with the non-ARC approach.

[Memnarch 24]

Not to mention:
If ManagedRecords work as good as what you can do in C++, you can write SmartPointers that enable reference counting when needed. Not just for objects but any memory blop you desire.

[Sherlock 663]

I guess it's a good thing I've been ignoring all of these then:

Quote

[DCC Hint] FMX.TMSEdit.pas(623): H2593 Code has no effect. Compiler generated temporary variable is cleared instead

😉

[Marco Cantu 78]

2 hours ago, Memnarch said:

Not to mention:
If ManagedRecords work as good as what you can do in C++, you can write SmartPointers that enable reference counting when needed. Not just for objects but any memory blop you desire.

That is part of the plan... we have some experimental demos, could evolve into a full feature

[Memnarch 24]

3 minutes ago, Marco Cantu said:

That is part of the plan... we have some experimental demos, could evolve into a full feature

Would love to see that. While I'm not an expert to C++, working with it in the UnrealEngine makes it so much simpler to identify ownership just by looking at the declaration of a parameter for example.

Which means: If an argument is not a Shared-Pointer, you can't store the value anywhere and only use it during runtime of the method. If it is a Shared-Pointer, you can keep that if needed. The Story of "Who owns it?" suddenly becomes very short 🙂

An exception here are UnrealProperties but that is blackmagic beyond the scope of what i wanted to say here 😉

[Dalija Prasnikar 1404]

4 hours ago, Marco Cantu said:

Honestly interested in feedback, suggestions and ideas. Less in "I told you" comments... 

I think most of EMBT customers will see that as a positive move. While I fully understand them, I am not so sure.

 

More thoughts... ARC is dead, long live ARC

[Lars Fosdal 1793]

I welcomed ARC in principle, but there were three key problems for me:
1. Having two different memory management models in our code base was not an option
2. ARC carried an unexpectedly high performance penalty 
3. The pitfalls of ARC were as many and as complex as for the classic reference count problems.

[DelphiRio 4]

IMO EMBT should create a new programming language and put ARC on it

[Markus Kinzler 174]

17 minutes ago, DelphiRio said:

IMO EMBT should create a new programming language and put ARC on it

Why? They just remove it from the llvm compiler(s).

[Dalija Prasnikar 1404]

2 hours ago, Lars Fosdal said:

I welcomed ARC in principle, but there were three key problems for me:
1. Having two different memory management models in our code base was not an option
2. ARC carried an unexpectedly high performance penalty 
3. The pitfalls of ARC were as many and as complex as for the classic reference count problems.

1. Totally understandable. You cannot use ARC to its full potential and you are only paying the price.

 

2. I assume it was Linux vs Windows,

It would be interesting to see how it compares with ARC removed. Comparing x86 with ARM is comparing apples with oranges - ARC or no ARC. AFAIK, LLVM backend has some influence on performance, too. There are some reports about inefficient code generation - something not ARC related. 

Performance mostly suffers because of existing code that is not written for ARC - unnecessary reference counting triggers are real performance killers. It is not fault of ARC per-se.  

 

3. LOL - it is the same memory management model, (if you remove DisposeOf out of the picture) so pitfalls are exactly the same. Developing for ARC requires a bit different mindset.

[Dalija Prasnikar 1404]

I found the report for Linux compiler that may have some impact on speed comparing to Windows (regardless of ARC)

 

Linux x64 compiler produce very bloated code

[Markus Kinzler 174]

Interesting. The problem might be present in the compilers for the mobile platforms using the same compiler frontend.

[Brandon Staggs 283]

On 10/26/2018 at 4:58 AM, Marco Cantu said:

Honestly interested in feedback, suggestions and ideas. Less in "I told you" comments... 

I have no problem with this. It makes me more likely to attempt projects that share code between desktop and mobile platforms, since I will not have to fight competing memory models. 

 

Personally, I would like to see some more work done on Interfaced objects. I use them more and more lately but certain things are a problem. For example, not being able to back a property with a field requires me to write far too much more code than I should.

 

This was a very bold move for you guys to take. You are essentially deprecating a massive chunk of how mobile works. I can't imagine this was an easy decision. I think it is a reasonable one and I have no problem with it.

[Edwin Yip 154]

On 10/26/2018 at 9:17 PM, Memnarch said:

Would love to see that. While I'm not an expert to C++, working with it in the UnrealEngine makes it so much simpler to identify ownership just by looking at the declaration of a parameter for example.

Which means: If an argument is not a Shared-Pointer, you can't store the value anywhere and only use it during runtime of the method. If it is a Shared-Pointer, you can keep that if needed. The Story of "Who owns it?" suddenly becomes very short 🙂

An exception here are UnrealProperties but that is blackmagic beyond the scope of what i wanted to say here 😉

@Memnarch, that's very interesting, would you point me to some example code? I don't know much about c++, thanks!

[Richard_Stevens 2]

Thumbs up from me. We have a couple of VCL products that make heavy use of relatively complex, object-based libraries that we debated moving onto mobile - but were put off by the rats nest of potential issues and number of IFDEFS it would have needed. If in 12-18 months' time we can re-use those libraries more or less "as is" then that will be great.

[Dalija Prasnikar 1404]

52 minutes ago, Richard_Stevens said:

Thumbs up from me. We have a couple of VCL products that make heavy use of relatively complex, object-based libraries that we debated moving onto mobile - but were put off by the rats nest of potential issues and number of IFDEFS it would have needed. If in 12-18 months' time we can re-use those libraries more or less "as is" then that will be great.

Just for the record, unless you have to change methods signatures - adding const param, and for some reason you need to keep old signature too, porting to ARC compiler itself does not require any IFDEFS. 

All needed changes are compatible with all compilers.

[Sherlock 663]

But you do get a bunch of warnings, @Dalija Prasnikar

[Marco Cantu 78]

On 10/26/2018 at 4:12 PM, Dalija Prasnikar said:

I think most of EMBT customers will see that as a positive move. While I fully understand them, I am not so sure.

 

More thoughts... ARC is dead, long live ARC

I think your last line "If we could have fresh start, without having the burden of existing code and frameworks lingering over our heads, ARC would be fine choice for memory management system." is a great summary I fully agree with. I still like ARC and I'm not happy with the decision. But would have been even less happy keeping the status quo (2 different models) forever. And we really cannot afford breaking VCL code (billions of lines of working code form our customers)...

[Dalija Prasnikar 1404]

@Sherlock If you get warnings, then this is kind of code that needs to be changed for ARC. But the change you do (depending on the actual code you need to change) will work across all compilers without warnings.

[Dalija Prasnikar 1404]

@Marco Cantu No matter how you turn it something is not quite right.

 

I can certainly see why you made the choice you made. Both now, and back then when ARC was introduced. I hope that for the sake of present we (saying we because non-ARC is clearly what your customers want) didn't sacrifice the future.

Edited October 29, 2018 by Dalija Prasnikar

[Memnarch 24]

On 10/28/2018 at 8:55 AM, edwinyzh said:

@Memnarch, that's very interesting, would you point me to some example code? I don't know much about c++, thanks!

Here is an example on SO

What i was referring to is std::shared_ptr. A SmartPointer is nothing more than a struct(record) which wraps some kind of pointer and does the lifetimehandling for you by doing actions when scopes are left or smartpointers are reassigned. The std::shared_ptr implements the same behavior we know from strings and interfaces in Delphi. Keeping a referencecounter on top of the allocated memory and freeing it, once the counter reaches zero. In C++ you wrap Interfaces into those, too, because the compiler does not call AddRef/Release automatically (the smartpointer does that for you). SO whenever an object is wrapped by a std::shared_ptr, you know you can safely keep the SharedPointer.

 

Previously, Delphi had no initialize/finalize and Assign operators on records(which are present in C++). Therefore it was impossible to write one(if you didn't want to wrap something in a wrapper TInterfacedObject, being much larger than a SmartPointer)

[Cristian Peța 107]

What if we would have [safe] attribute?

It would be very useful for local instances. 

 

We have [unsafe] attribute but not [safe]. In ARC all instances are implicitly [safe] and we need to explicitly mark with [unsafe] if we don't want ARC.

I call this implicit ARC.

 

But with [safe] we can have explicit ARC where all instances are implicit [unsafe].

 

 

var ms := TStringList.Create;
try
  ...
finally
  ms.Free;
end;

var [safe] ms := TStringList.Create;
...

Merged by Sherlock: Try to avoid double posts, please.

Edited October 30, 2018 by Cristian Peța