Writing in .NET languages,
e.g. C#, is beneficial in that the programmer need not worry about
memory management as .NET provides a convenient dynamic memory facility
where unreferenced objects are removed automatically by the garbage
collector (GC).
HALCON/.NET makes use of this concept.
.NET variables
.NET data types can be classified according to whether a variable
of a particular type stores its own data or is a pointer to the
data. If it stores its own data, it is a value type;
if it holds a pointer to data elsewhere in memory, it
is a reference type. Value types are numerical types
like int or double and structs, while strings and all classes
are reference types.
The most important thing to keep in mind for all classes
from the HALCON/.NET interface is: HALCON Variables in .NET are
only references to data.
This means that reference types do not contain the actual data
stored in a variable, but they contain a reference to the variables.
That is, they refer to a memory location.
Furthermore, referenced data is never overwritten by assignments.
When a variable is assigned a new value, the old data is dereferenced
and memory is allocated for the new data.
Garbage Collector - points to note
The garbage collector tidies up data that
is not referenced any more - either because the variable
leaves its scope or it is not referenced by any part of the code
anymore. The garbage collector becomes active when the
estimated size of allocated memory exceeds a certain threshold.
In the context of HALCON, the garbage collector only recognizes
the object structure, to which the variable points, plus the managed
data. Managed data is referenced in HTuple, whereas HObject contains
unmanaged data which is not recognized by the garbage collector.
HALCON's iconic variables (images, regions,...) seem to be rather
“small” for the garbage collector, because they only
contain a reference to the (in many cases rather large) iconic
objects in the database. Thus, the garbage collector may not free
such variables even if they are not used anymore.
Especially in loops, this causes .NET to repeatedly allocate
memory for the new instantiation of images, as the data is not
overwritten. The garbage collector in turn does not see the constant
increase of required memory. In some cases memory consumption
grows such that one may observe error 6001 (not enough memory)
for no obvious reason.
To release this memory, the garbage collector
can become active nevertheless by calling it explicitly:
GC.Collect();
GC.WaitForPendingFinalizers();
A good point for calling the garbage collector would be at the
end of the main processing loop. This makes sure that your .NET
application releases memory regularly in each cycle.
Manual disposal
The manual disposal of individual objects is also possible by
calling the method Dispose. The Dispose method
is especially useful in small loops where the direct call of the
garbage collector is too expensive.
Interface
revision update |
MVTec has updated
the following interface revision: HALCON 10/11 OpenNI interface
(revision 4.4 / 5.2)
Please contact us for download
details |