Blog post "Directions for ARC Memory Management in Delphi" at http://blog.marcocantu.com/blog/2018-october-Delphi-ARC-directions.html

Blog post "Directions for ARC Memory Management in Delphi" at http://blog.marcocantu.com/blog/2018-october-Delphi-ARC-directions.html
http://blog.marcocantu.com/blog/2018-october-Delphi-ARC-directions.html

Comments

  1. Good choice.

    Something you did not mention is that removing ARC opens up the road for (optional) GC down the road without having to battle ARC all the way.

    It is possible to make a GC coexist with a manually-managed memory model. The missing bit was for the GC to "know" what's in stack-based scope, and that is something the new record constructors/destructors already allow if I understood correctly.

    A crude version could be instead of just

    myVariable : TMyObject;

    you could do

    myVariable : GC;

    the difference with a class interface-based approach would be that GC<> does not just acquire an interface from the object, but also places that interface in a "scope list" alongside RTTI for TMyObject.

    If/when the interface goes out of scope, if its refcount is zero, then end of story for that instance (same as ARC).
    But if not (such as in a cycle), a background thread can go through the scoped GC<> entities with a classic GC algorithm, and prune all the cycles.

    The GC<> can the later be bundled into class type with a prefix for visual recognition (f.i. CMyObject = GC) or other syntax sugar.

    Even if you never plan to use a background GC, the GC scope list could also be used in debug mode to improve memory leak diagnostic (rather than just report leaks, you could then report "superstructures" of the leaks by pinpointing which top-level objects are the root of the leaks)

    ReplyDelete
  2. It's a very wise decision. After abandoning ARC and introducing of native controls in Delphi for Android in future versions, I hope Delphi mobile applications will become smaller in size and more responsive.

    ReplyDelete
  3. What makes me sad is that the whole NextGen aftermath will be we are stuck with #$!%@?? Zero Based Strings, and the only worthwhile feature ARC is removed.

    ReplyDelete
  4. Dalija Prasnikar I still have hope that we will get rid of the former, too.

    ReplyDelete
  5. Meh. So until we get a proper way to automatically let the runtime manage memory for us in the normal 95% of use cases we are stuck back in the 90s for another half a decade I guess...

    ReplyDelete
  6. Eric Grange I'm already using a similar approach for a long time , made by SO user CodeAndCats (https://stackoverflow.com/a/418206/133516), usage look like:

    procedure Test;
    var AQuery: TQuery;
    begin
    AQuery := TQuery.Create(nil);
    GC(AQuery);
    ...
    end;

    It's working very very well for me.

    stackoverflow.com - How to automatically free classes/objects?

    ReplyDelete
  7. Edwin Yip your approach is actually quite different, as it cannot automatically handle cases where the reference is passed around to other methods, copied to fields, captured in closures etc. and it also cannot handle reference cycles on its own.

    What I refer to is using the new records for "boxing" references so you have access to not just entering or leaving a particular scope, but also to copies of references, so that you can maintain a "global list" of references, and can then leverage RTTI on that list to perform a full blown GC (like mark and sweep).

    The GC<> I referred is not there to acquire an interface from the instance, but more to maintain the "global list" (quoted because while it can be conceived as a global list for discussion purposes, performance would dictate a different structure)

    ReplyDelete
  8. Are there plans to go further and make 1-based strings default on mobile? "Rip the band-aid off" in 10.4 and focus on compatibility across all platforms?

    ReplyDelete
  9. Darian Miller You can use ZBS on all platforms

    ReplyDelete
  10. David Heffernan Yes, but having an existing set of code without a bunch of IFDEFS is difficult to maintain across platforms. Full compatibility should be a primary goal, especially if you are trying to grow the language with new developers. Have this conversation with a new Delphi dev who maybe has inherited an existing codebase (or has downloaded a bunch of example code) and wants to branch out to Mobile: stackoverflow.com - How to work with 0-based strings in a backwards compatible way since Delphi XE5?

    ReplyDelete
  11. Darian Miller I think the way forward is to stop supporting older versions of Delphi that don't have ZBS

    ReplyDelete
  12. David Heffernan WHAT? But how am i supposed to compile my cool FMX Mobileapp under Delphi 7?! /sarcasm

    ReplyDelete

Post a Comment