Unified Memory Management - Coming with 10.4 Beta

-
As announced on previous roadmaps, the 10.4 release of Delphi is planned to have unified memory management. That means retiring the ARC compiler on mobile platforms, which will now operate under the same good old manual memory management model that originated on Windows.

Unification is good. Completely different memory management models require slightly different code. That alone breaks the promise of a single code base for all platforms. In reality, if you need to target platforms with different memory management models you will find yourself coding under the requirements of manual memory management where ARC will only throw you some curveballs. Constrained ARC is bad ARC, it is not useful, it cannot unleash its full power.

On one side I am happy because of unification, on the other I am sad to see the ARC compiler go. It had great potential and was mostly brought down by unoptimized RTL/FMX code that was written for manual memory management. There is a whole lot of code that could be written cleaner, simpler under full ARC. There is a whole a lot of fiddling around we could avoid. Oh, well, you can't win them all.

Anyone using Delphi on mobile platforms will have to check their code and make adjustments for the new (old) memory management model. Any shared code that is already working on non-ARC platforms will continue to work as-is. Changes are only required in code that was exclusively running under mobile ARC compilers, relying on automatic memory management for object instances.

Retiring ARC compilers also means DisposeOf will be retired, too. Hooray!

I assume that DisposeOf will just be deprecated for the time being, so you will not have to change code that uses it (on the classic compiler it calls Free, so the functionality is the same), but you will be able to completely remove it if you wish.

I expect that removing ARC will give a significant performance boost to mobile applications. But, mostly due to RTL/FMX code that is not optimized for ARC compiler, not the ARC compiler itself (even though ARC will always add some performance overhead, code that is not optimized for ARC adds a lot more).

For more information on other upcoming features and participation in the 10.4 Beta program, go to:
Get ready for the 10.4 Beta with Update Subscription

Comments

  1. Pie O MyMarch 18, 2020 at 12:05 PM

    Hi,

    I have only 1 question, Application.ProcessMessages; will it work on android? ( inside for loops to update UI )

    Thanks

    ReplyDelete
    Replies
    1. Dalija PrasnikarMarch 20, 2020 at 8:37 AM

      Application.ProcessMessages is not related to memory management.

      It is obsolete on Android and it will never work again. Change happened in Tokyo when FMX UI thread was no longer separate thread on Android and now it is the same as Android UI thread.

      That change occurred because having two UI threads created number of issues in FMX applications when interacting with Android OS. This was bug fix change and because of that it will never be reverted.

      Delete
    2. Pie O MyMarch 20, 2020 at 12:13 PM

      Thank you for answer.

      I don't know deeply how they work, just developing simple apps.

      Delete
  2. Brian ThomsonJune 3, 2020 at 7:42 AM

    I am happy to see the change. ARC (Automatic Resource Counting) has always been possible in Delphi even though it took a bit more work. Because of the memory management disparity between running on windows without ARC and running on other platforms with ARC I was writing all of my code, that could use it, to make use of ARC in both Windows and Android. Turns out that was a wise choice as all of my code now requires no changes.

    ReplyDelete
    Replies
    1. Brian ThomsonJune 3, 2020 at 7:42 AM

      I should amend that to say that ARC has been possible in Delphi for many years. It was not always as easily implemented as it is today.

      Delete
  3. JohnJune 14, 2021 at 6:22 AM

    Hi Dalija,
    Are you aware of any performance issues regarding the new Unified Memory Management?
    See e.g. https://quality.embarcadero.com/browse/RSP-34106

    ReplyDelete
    Replies
    1. Dalija PrasnikarJune 15, 2021 at 12:33 AM

      This has nothing to do with unified memory management. If anything no ARC on mobile platforms is faster than ARC, because there is no reference counting overhead.

      On other platforms, memory management is the same as it always was - unification means that memory management on mobile platforms now works the same way it always worked on Windows.

      There were other changes in FMX code that could have caused this, and additionally in 10.4 implementation of custom managed records added some overhead when constructing/destroying objects - there were some fixes around that area and I don't know what is the current status, but as far as I know this particular issue cannot explain the difference observed in RSP-34106.

      Anyway, whatever is the cause here, it is not related to unification of memory management.

      Delete
    2. JohnJune 15, 2021 at 12:40 AM

      Ok, thanks for your explanation Dalija.
      Hopefully they find a fix for it soon because it has a big impact on performance at the moment.

      Delete

Post a Comment

Popular posts from this blog

Catch Me If You Can - Part II

-
It has been quite some time since I wrote the Catch Me If You Can post about the inability of LLVM-backed compilers to catch non-call hardware exceptions. In other words, hardware exceptions raised by code written in the same block as the try...except exception handler. Since then, more LLVM-backed compilers have been added to Delphi, and with those, more reasons to change common coding practices... but still, very few developers know about the issue. The original article covered only try...except exception handlers, and exploring what exactly happens with implicit and explicit try...finally handlers was left as an exercise to the readers and to some future, now long overdue, post. And Now: All Hell Breaks Loose When you read about non-call hardware exceptions not being caught by an immediate try...except block, the implications might not look too serious. After all, while plenty of code can raise exceptions, try...except handlers are not that frequently used in places, as mo
Read more

Delphi 12.1 & New Quality Portal Released

-
Image
The Delphi 12.1 update has been released. Besides a number of bug fixes, this release also has a few new features. The most notable ones are the new Split Editor, which allows having multiple files opened side by side; and support for Android API 34. You can find more information about what is new in this update at https://docwiki.embarcadero.com/RADStudio/Athens/en/12_Athens_-_Release_1 However, the greatest change for all Delphi developers is a new bug tracking portal that replaces the old one, still available in read-only mode at https://quality.embarcadero.com/ . The new portal is hosted in Atlassian Cloud https://embt.atlassian.net/servicedesk/customer/portals  or through a redirect https://qp.embarcadero.com and is based on Jira Service Management (JSM), while the internal bug tracking system, which was also migrated to the cloud, was not changed and is running on Jira. This move to the cloud was inevitable, because Atlassian retired their Server line of products. JSM is a
Read more

Coming in Delphi 12: Disabled Floating-Point Exceptions

-
Delphi 12 is in the works. One of its small features that will have a huge impact is a change in the default handling of floating-point exceptions, which will now be masked on all platforms. Previously, floating-point exception handling was different across platforms, and most notably on the Windows platform: In VCL and console applications, floating-point exceptions were not masked and would raise an exception. On the other hand, FireMonkey applications had all floating-exceptions masked by default, regardless of which platform they were running on. Basically if you haven't explicitly changed the exception mask in your code to some value other than the default, and you had code that attempted to divide some number with zero, you would get an EZeroDivide exception in previous Delphi versions on the Windows VCL application. In Delphi 12, there is no exception, and the result of such a division will be +INF . So the following code will no longer raise an exception. If you were r
Read more