background
In ISA, the memory is managed thru smart pointer and reference (See Identity assembly) because of the efficiency and simplicity of this approach. This have been discussed in several places on this blog and elsewhere and will not be more exposed here.
On usual historical systems, the Operating System (O.S.) also provides Processes. This is the general way to manage memory (and other resources). On ISA, the intention is to break the walls the Objects are prisoner of. The process is one of most important jail.
But! If there is no process to manage memory globally, how that will be handled in ISA?
The closest notion, but different in essence, is the use case. This is the artifact initiating directly or indirectly all objects. So we have to find a way to manage the memory with smart pointers and use cases.
What is the problem?
In broad words, smart pointer acts in a relevant way within a process. The first reason to that is because they manage accurately allocation and deallocation of objects as the program run.
And, also, because when the process finishes all the allocated memory is freed.
Without processes, objects can reference themselves circularly without a use case in the pointers graph. The smart pointers remain with reference counter greater than 0. Therefore, the memory for these objects is never freed!
This first suite of diagrams below explains the problem.
When the SampleUseCase is finished, the reference on SmartPointerLuc and SmartPointerSylvie are removed.
However, the circular references among objects involved by the SampleUseCase remain. This abnormally prevent the memory to be freed.
There are objects with circular dependency that remain loaded in memory. This is a memory leak.
Add a use case reference counter to smart pointer
In ISA, use case is the artifact to launch functionalities. The end of a functionality is the end of the corresponding use case scenario.
With both on one hand an additional use case reference count on smart pointer, and on the other hand a use case finalization process that detect orphan's objects cycles; the memory can be wholly and accurately freed.
This second suite of diagrams below illustrates the solution.
When the SampleUseCase is finished, the references on SmartPointerLuc and SmartPointerSylvie are removed.
The scheduled process of search for cycle without Use case counter greater than 0 is run. The involved objects in this kind of cycle are removed. The operating system is responsible for that (refer to System assembly for more details).
The process is executed for each smart pointer referenced by a use case.
Therefore, all the useless objects will be removed from memory.
This has zero performance impact since this is done after than the use case scenario is finished. Moreover, the search cycle process is ran in background at a low priority.
A more complete example
The sequence diagram and object diagrams below detail what happens.
