Unified Memory Management - Coming with 10.4 Beta

[Guest]

Great news from Dalija Prasnikar! Thank you!

 

https://dalijap.blogspot.com/2020/03/unified-memory-management-coming-with.html

 

[Rollo62 536]

I used manual memory handling too, so the change should be fine for me.

 

But I hope that there won't be too many strange, unexpected errors, caused by the changed Free/Dispose timing now.

[David Heffernan 2345]

Unification is good. Going to cause headaches for anybody with ARC only code. Don't think that's going to be an easy migration path.

 

Such a shame that this happened at all, but good for Emba for having the strength to change direction. 

[Dalija Prasnikar 1396]

43 minutes ago, David Heffernan said:

Unification is good. Going to cause headaches for anybody with ARC only code. Don't think that's going to be an easy migration path.

While anything is possible, I don't think there is too much ARC only code around. For anything TComponent based ARC was never working in the first place (you had to use DisposeOf) so most of UI code should work as-is.

 

Since manual memory management is what people are used to, migration path should be relatively easy, although it may be harder to find exact places where object needs releasing. I would follow constructors .Create - usually destruction is somewhere nearby - either in Destroy, or in the same method. Also, on mobile small leaks are not that critical, usually applications are killed anyway before such leaks cause substantial problems, and larger leaks are easily found just by looking at code.  With Instruments and Android Studio you can easily spot problematic parts of  application with large leaks.

 

Not ideal situation... but what is done is done.

Edited March 4, 2020 by Dalija Prasnikar

[Sherlock 663]

I actually never heeded the warnings my FMX code generated when in ARC mode. I need Windows as well so...good on me, for once.

Edited March 4, 2020 by Sherlock
Fixed a stupid spelling error

[Clément 148]

I was not using FMX for serious development, so for me nothing will change at all.
Except, maybe I will give FMX another try. Hopefully FMX will improve faster without ARM. There's a lot to catch either to match VCL counter part or Android Studio! 

 

What I really want to see:

1. Bug Fixes

2. RTL Improvement / optimization

3. Debugger Stability Win32 AND Win64

4. IDE Quality

5. Language Server Protocol for Delphi

6. Language Enhancements: Managed Records 
7. Unified memory management across all platforms 
8. VCL High DPI Styles Support 
9. VCL Per Control Styling
10. New VCL Components
11. Updated VCL styles for HighDPI
12. Windows API Updates

[Dalija Prasnikar 1396]

5 minutes ago, Clément said:

Except, maybe I will give FMX another try. Hopefully FMX will improve faster without ARM. There's a lot to catch either to match VCL counter part or Android Studio! 

I assume you meant "FMX will improve faster without ARC. "

 

But, no, FMX improvements (as in framework improvements) are in no way related to memory management model. The only difference between FMX and VCL code related to memory management is that FMX calls DisposeOf to release FMX components and VCL calls Free. Bottom line, FMX will just run faster on mobile platforms without ARC, but that is it. 

 

Other improvements will come (or not) unrelated to the memory management mode change.

[Clément 148]

21 minutes ago, Dalija Prasnikar said:

I assume you meant "FMX will improve faster without ARC. "

ARC! I need coffee for my memory management

 

[Eli M. 38]

We have a maybe ~40k-50k LoC iOS app in FMX for 5+ years and it only ever has had maybe 1 place it specifically needed DisposeOf and/or [weak]. Everything else just uses Free as it supports Windows as well.

[Kryvich 165]

I would like to see in some future version of Delphi:

• Iif operator - a magic function to write compact and effective statements of any type.
• Class contracts ("require", "ensure" clauses, https://www.elementscompiler.com/elements/oxygene/language.aspx) 
• Nullable types and ":" operator, https://www.elementscompiler.com/elements/oxygene/language.aspx#colonoperator .
• "await" and "async" clauses for smooth multithreading.

Edited March 8, 2020 by Kryvich

[Guest]

Only partially OK... why not ARC or adding Garbage Collector? Manual memory management is pain and only slows you down. I understand that at least ref. counting for interfaces remains, at least this one.

 

They should remove this silly copy/paste of undisclosed getters/setters for properties exposed under interface, and why they require getters/setters in first place there. They should remove that sort of things too.

 

[Anders Melander 1783]

15 hours ago, Kryvich said:

I would like to see in some future version of Delphi

How is that relevant to the topic?

[Anders Melander 1783]

12 hours ago, TomDevOps said:

Manual memory management is pain and only slows you down.

You should probably rephrase that "and only slows me down".

 

In my experience laziness always comes at a price. Not bothering to use descriptive identifiers saves a few keystrokes at the price of readability. ARC and GC relieves the developer of having to deal with some of the complexities of resource management, at the price of performance. Etc.

 

I would honestly rather have good performance and full control of what's going on with the resources.

 

 

12 hours ago, TomDevOps said:

They should remove that sort of things too.

Yes. Let's break COM support so we can save some keystrokes.

[Guest]

18 hours ago, Anders Melander said:

You should probably rephrase that "and only slows me down".

Not really... I would argue that this applies to anyone 👹

 

18 hours ago, Anders Melander said:

In my experience laziness always comes at a price. Not bothering to use descriptive identifiers saves a few keystrokes at the price of readability. ARC and GC relieves the developer of having to deal with some of the complexities of resource management, at the price of performance. Etc.

 

I would honestly rather have good performance and full control of what's going on with the resources.

...and you will spend much more time 🙂 I do not dismiss performance and stuff, but then use C/C++ 😈 It is rare to use one language for all use cases.

 

Pretty much all mainstream languages have either ARC or Garbage Collector; and neither ARC or GC are perfect, still C# can outperform Delphi, thus in my view, GC is not always a problem.

 

18 hours ago, Anders Melander said:

Yes. Let's break COM support so we can save some keystrokes.

Not necessarily... why not to use pre-processor sort-of-thing to generate stuff like this for compiler? Why we have to make this big bulky header section? The more I write in Swift or C#, the less I like Delphi.

 

But anyway, for dead language with no future, it probably does not matter at all and I guess I should be happy that it happens to be that Delphi is still quite modern so some legacy code, still out there, can be even improved.

Edited March 9, 2020 by Guest

[Sherlock 663]

16 hours ago, TomDevOps said:

But anyway, for dead language with no future, it probably does not matter at all and I guess I should be happy that it happens to be that Delphi is still quite modern so some legacy code, still out there, can be even improved.

Well luckily this is not a Cobol forum - no wait, even that will not die (german article on 60 years of Cobol: https://www.heise.de/developer/meldung/60-Jahre-COBOL-Die-Sprache-die-nicht-totzukriegen-ist-4518334.html) Then another surely dead language maybe, let's try Fortran ... oops, not dead (https://www.vortech.nl/en/fortran-is-alive/).

TL;DR: Don't make unsustainable claims. 😉

[Guest]

46 minutes ago, Sherlock said:

Well luckily this is not a Cobol forum - no wait, even that will not die (german article on 60 years of Cobol: https://www.heise.de/developer/meldung/60-Jahre-COBOL-Die-Sprache-die-nicht-totzukriegen-ist-4518334.html) Then another surely dead language maybe, let's try Fortran ... oops, not dead (https://www.vortech.nl/en/fortran-is-alive/).

TL;DR: Don't make unsustainable claims. 😉

You missed the point, those languages are long dead... there are almost no jobs. This is the bottom line. That is, dead language is not literally dead and you can try to find jobs and write in them, but it will be very hard to do so, so either there are jobs for maintaining legacy system or to support re-writing process; and barely you can find new development - why? Back to square one, there are just few developers on the market. That is the whole point 😉 

 

This is important, show me the actual job list for Delphi in let's say Paris (assume I cannot relocate due to family), do the same for Fortran/Cobol. And how many new development is done in Fortran and Cobol? Almost none. Thus, people will not invest their time into technology in which you cannot find a jobs. This is interlocking problem, I doubt Cobol, Fortran, Delphi, Basic, Modula-2 etc., will ever gain more attraction. That would still a niche technology.

 

TL;DR: the language is dead when there are almost no jobs for it, leaving only few maintaining legacy code jobs.

[Daniel 417]

Please stay on topic.

[Sherlock 663]

Sorry, boss.

[Vince Bartlett 1]

Resurrecting an old thread...

Anybody aware if unified memory management will be in 10.4?

I've kept an eye on Marco's blog and it's not mentioned....

[Darian Miller 361]

It's mentioned: 

https://blog.marcocantu.com/blog/2020-march-getready104beta.html

https://www.tatukgis.com/Blogs/Blog/May-2020/RAD-Studio-10-4-Sydney-is-coming.aspx

https://community.idera.com/developer-tools/b/blog/posts/delphi-10-4-sydney---delphi104---tag-comingsoon

 

List of links available: https://github.com/ideasawakened/DelphiKB/wiki/D27.SYDNEY.10.4.0.0

[Dalija Prasnikar 1396]

https://dalijap.blogspot.com/2020/03/unified-memory-management-coming-with.html

 

Yes, 10.4 will have unified memory management on all platforms.

[Fr0sT.Brutal 900]

Surprisingly, ARC <> GC