Posts

Is it leaking or not?

-
Catching memory leaks on the ARC compiler can be a daunting task. Even if the destructor of an object instance is called, that still does not mean your object is completely released.
In the classic desktop compiler, a quick test to see whether some object instance was released or not was to add a breakpoint (or some logging code) into the destructor, and if you got there, all was good. This is not the case with the ARC compiler.

The last method called in the object instance lifecycle after which all instance memory will be completely released is TObject.FreeInstance. While this method is common to both ARC and classic compilers, on the classic compiler executing the destructor would inevitably (unless it throws an uncaught exception) mean executing FreeInstance and completing the release cycle. On the ARC compiler, there is no such guarantee. The destructor can also be called directly via DisposeOf, and FreeInstance will be called only after all strong references to the object are c…
Read more

Git the Princess the Delphi Way

-
Image
First of all, Delphi developers don't know how to Git the princess, they only know how to Subversion.



You are an experienced Delphi developer with 20+ years in the field. Actually, there are no other kinds of Delphi developers. You know how to save the darn princess. You are done while others are still prototyping.

You use FireMonkey to git the princess. You accidentally trip over the undocumented dragon sneeze button. Now, the castle is on fire, the princess in on fire, you are on fire...

You start on Saturday, there is a new Tokyo update. Godzilla jumps out of it, demolishes the castle, makes the dragon run for his life, and squashes the princess.

You start on Saturday, there is a new Tokyo update, and it triggers a license check error with an ancient Delphi 7 installation. While you wait for Monday to get support, others have pulled the princess and there is none left.

Inspired by https://toggl.com/programming-princess/
Read more

Don't mix objects and interfaces

-
Image
Mixing objects and interfaces in classic (non-ARC) Delphi is a huge no-no. That part is clear. What that actually means is more of a blur. After all there is a object instance lying behind every interface reference.

So what is wrong with mixing objects and interfaces?
object references are weak, interface references are strongreference counted object instances need at least one strong reference to keep them alive therefore you can't use object reference as primary owning referencereference counted object instances can be safely accessed through temporary, short-lived (weak) object references, as long as there are strong reference(s) keeping the object alive

The real issue behind the mixing of objects and interfaces is not the mixing itself, but the lack of initial strong (interface) reference to object instance, or accessing the reference counted object instance through weak (object) reference after the last strong (interface) reference has gone out of scope and the object has alr…
Read more

Optimizing ARC - weakness of [weak]

-
In Delphi, the [weak] attribute is used to break strong reference cycles between reference counted object instances. It can be used with the ARC compiler on both object and interface references, and with the classic compiler for interface references. Weak interface references were introduced in Delphi 10.1 Berlin.

Now, there is a teeny-weeny problem with the [weak] attribute. It denotes a zeroing weak reference that will be zeroed (niled) when the object it points to is no longer valid. In order to do that, the compiler has to track such objects at runtime and that introduces some overhead. If you are tracking many such references, that can introduce a significant performance loss.

Not all weak references that serve the purpose of breaking reference cycles need to be zeroed out. If you can guarantee that a [weak] reference will never outlive the object it points to, all that tracking and zeroing is useless. To avoid a performance penalty in such cases, you can use the [unsafe] attribu…
Read more

Exceptional Safety

-
Delphi is exception safe language. That means well written code can recover from the most horrible exceptions, including the dreaded out of memory error, and continue running in a perfectly operational state - as if nothing bad happened. Of course, that is a feature that Delphi provides, but your code and application eventually must determine logic at which point raised exception is recoverable and at which point it is not.

For instance, if you allow user to open some external file for further processing and your code trips on out of memory exception because the file is too large to process, you can fully recover from such event, show error message to the user "Sorry, selected file is too big" and application can merrily continue working. On the other hand if you trigger out of memory error during some operation your application absolutely must be able to perform, you can decide that the best course of action is terminating the application - after you show appropriate error …
Read more

Optimizing ARC the hard way

-
One of the potentially unnecessary ARC triggers is passing a reference counted entity as a parameter. Depending on the parameter's declaration, the compiler might insert transient reference counting code in the prologue and epilogue of the called procedure (function, method).

Parameters passed with the default (value) semantics will trigger the reference counting mechanism. On the other hand, parameters passed as references - declared as var, const, [ref], [weak] or [unsafe] - will not trigger the reference counting mechanism while entering and exiting the procedure.

There is nothing new here. Delphi COW copy-on-write strings are reference counted, and passing strings as const parameters is a commonly used optimization pattern. The same principle applies not only to strings, but also to all other reference counted entities, like dynamic arrays, variants, interface references, anonymous method references, and additionally object references on Delphi ARC compilers.
Why the hard way?…
Read more

Optimizing ARC with unsafe references

-
Image
ARC recognizes two types of references: strong and weak. Strong references are ones that participate in the reference counting mechanism, and weak references are references that do not participate in reference counting.

While there is more than one way of achieving weak references, the ones that conceptually fit into ARC memory management are zeroing weak references. Zeroing weak references are niled (set to zero) when the object instance they point to is destroyed. A combination of strong and zeroing weak references leaves no room for invalid pointers. At all times, you will be dealing with references that are either nil or point to a valid object instance.

Sounds perfect, doesn't it?

Well, at least in theory. In practice, just like reference counting itself adds some small amount of overhead, zeroing weak references add some more. In order to zero out weak references after the object instance they point to is destroyed, the application has to track them at runtime and that can be…
Read more