Sunday 31 January 2016

X++ in AX7: Garbage Collection

In AX 2012 the runtime can either be the .NET CLR executing IL code, or the AX interpreter executing pcode. From a Garbage Collection point of view these two behaves extremely different. The difference is like night and day.

In AX7 only the .NET CLR Garbage Collector is in play.



Native AX interpreter.NET CLR
TriggerImmediately – when reference count reaches zero.Indeterministic – usually when system is low on memory or idle. Can also be on demand.
Performance
Maintaining the reference counts is expensive. More info.
Freeing memory in-proc is expensive, slowing down transactions, etc.
Designed for minimal impact at runtime.

Who cares?

In most situations you don't have to care. The .NET GC will do what you expect. However; if you are dealing with any unmanaged resources, you have to pay attention.


Locks in SQL is a typical unmanaged resource. If your logic uses the UserConnection class to obtain a lock in SQL, and you rely on the GC to release the lock (by aborting the user connection's transaction), then you will experience the lock not being released as you expect. In fact, you may notice it never gets released.


The ReqReaderWriteLock class in AX2012 was doing exactly that. In AX7 this classes is now implementing the System.IDisposable interface. Consumers must ensure dispose() gets invoked. The using statement is handy here.

No comments:

Post a Comment