Memory allocation in Cind language is carried out by the Cind execution software
(which is a software, that executes programs written in Cind language).
There are no memory allocation nor memory freeing instructions in Cind programming language.
Phisical memory allocation are managed by Cind execution software,
depending on the needs and type of the executed application.
Total size of the memory used by a specific Cind program
mostly depends on the number of created and used objects
and on the number of concurrently executed threads.
x = new a.b.c();
Creation of each object, thread, array or other language structure
requires reserving appropriate piece of memory.
For example, this statement:
creates new object, and therefore it reserves some piece of memory
(of internal memory of execution software),
that will represent the object and in which all object information will be stored.
To remove unused memory, Cind execution software uses mechanizm called Garbage collector.
A garbage collector is a method to manage memory by removing unused fragments of memory
(unused objects, threads and other data) - called garbage,
by marking used fragments and rewrite them to some other memory segment.
Garbage collector, implemented in the Cind execution software,
is running periodically during program execution,
and when it is launched, it can work in two ways:
- by suspend the application while making cleanup, or
- it makes cleanup concurrently to the application's threads.
It is not specified when garbage collector will be launched.
The way of executing garbage collector depends on the application behaviour.
For instance, when application makes many garbage in small time,
then the first method will be choosen, but when application mostly sleeps
(for example, it waits for incomming network event), then the second method will be choosen.
When garbage collector detects unsued objects (and before it removes them from memory),
it will execute objects' destructors (for more about destructors see Classes).
Destructors are executed concurrently to the main application.
Notice, that during destructor execution, the indicator objects
host and caller
may be different from the ones used in application (see Indicator objects),
because garbage collector works out of any context.
That is, destructor's code may be executed "blindly" without any connection with the application.
Notice also, that it is not determined when or even ever garbage collector
will execute the objects' destructors.