Dana release notes: v234

Release date: 24th April 2020

It's been a while since our last update -- the world is in a strange place at the moment, so things are slower. There also isn't yet a release build for this version supporting 32-bit Ubuntu, as we don't have access to our development machine at the moment.

This update is a big one, with a new variable qualifier giving a higher level of adaptation safety, and a full garbage collector for unmanaged memory.

The store qualifier

Dana has always been designed primarily to support runtime adaptation by hot-swapping components. The rules of the language guide the programmer to write code which is inherently adaptable as far as possible, and which results in a sound system post-adaptation.

Until now, the key area in which we couldn't protect systems during adaptation was in stateful side effect channels that could persist after adaptation. This is a very subtle effect, but can have severe consequences to system stability if we get it wrong.

We can check side effect channels by requiring the programmer to tell us something very simple in an interface: whether or not a parameter is intended to be saved in the global state of the object instance implementing that interface. In Dana v234 we allow the programmer to specify this using the new qualifier 'store' on parameters. This is almost always very easy to decide in advance, but provides the language with a much higher level of reasoning about side effects.

The compiler and runtime will now advise you on whether or not parameters need a store qualifier on them. Because local variables in a function can be assigned from parameter values, we also need to allow local variables to have the store qualifier. The key constraint this concept enforces is that global variables cannot have values assigned from any parameters, or any local variables, that are not declared with store.

This release fully implements the fundamental store concept so that future systems are guaranteed to have this extra adaptation protection, but future Dana releases also will have much more intelligence in the compiler so that you will rarely need to use store on local variables (only on function parameters in interfaces). You'll also see that the Dana API now includes store annotations.

You can read more about this in the guide at http://www.projectdana.com/dana/guide

Garbage collector

Dana has always had a simple reference-counting garbage collector, which automatically frees up memory but only if there are no cycles in reference graphs. While this is kind of OK for a prototype, it doesn't work for a production-class language.

This version of Dana for the first time has a full cycle-detecting garbage collector, which operates on what -we call unmanaged memory. To help make the garbage collector efficient, we define two kinds of memory usage: managed and unmanaged.

Managed memory is that which has been created by an object by instantiating data items, arrays, and objects. As long as these items are referenced by their creating object, we call them managed. Dana uses a simple reference-counting garbage collector for managed memory, so the programmer is still responsible for removing circular references here.

Unmanaged memory is any data instance or array which has been passed to an object that did not create it, where the creating object no longer has a reference to it. In this case, the owner of the instance is no longer \"managing\" the memory, so Dana's full cycle-detecting garbage collector operates on these instances to automatically detect circular references and free the memory when it is no longer referenced.

We use this hybrid approach because garbage collection is expensive, and the design of Dana makes it easy in most cases for objects to manage their own memory by ensuring that it can be free'd by a simple reference-counting algorithm.

You can also read more about memory management at http://www.projectdana.com/dana/guide