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


  1. Hi,

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


    1. 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.

    2. Thank you for answer.

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

  2. 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.

    1. 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.

  3. 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

    1. 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.

    2. 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.


Post a Comment

Popular posts from this blog

Coming in Delphi 12: Disabled Floating-Point Exceptions

Beware of loops and tasks

Catch Me If You Can - Part II