Base class for a bucket element allocator using malloc function bypassing
the GC.
By default the class constructor checks the type of the Bucket elements
(i.e, the values stored in the Map). If the element contains reference
items (e.g class or an array) then on malloc allocations the class adds the
elements to the GC scan range and removes them from the GC scan range on
recycling.
This tracking of the objects can be explicitly disabled through passing
the appropriate flag to the class constructor.
Warning :
Do not disable the tracking of the allocated elements except if the
element if there is another reference to the GC allocated items
elsewhere.
The following is a more detailed explanation about what's safe to store
without GC tracking and what's unsafe.
If the elements stored in the map (i.e the struct or class you are
storing) contains a GC managed memory item and the single reference to
this memory is only in this malloc-based map then the GC will collect
this data as no other GC object is referencing it. Once collected you
will end up with segmentation fault when you to access this non-used
memory address.
For example, consider that what you are storing in the map is the
following :
structS
{
statucclassC
{
}
statucstructS2
{
floatx, y;
}
inta; // Not a problemS2s2; // Not a problem, S2 doesn't contain GC allocated memory.int[] arr; // Problem: Arrays memory are managed by the GCClassc; // Problem: class C is tracked by the GC.staticSopCall()
{
Ss;
s.c = newC();
returns;
}
}
This reference items doesn't have to be added to the GC scan list if
it has another reference in the GC (e.g when another reference exists
in a pool).
For example:
structGCTrackedObject
{
int[] arr;
}
staticStructPool!(GCTrackedObject) arr_pool; // Tracked by GCstructS
{
.
// Same code as above
.
ObjectPool!(C) c_pool; // Tracked by GCstaticSopCall()
{
Ss;
s.c = c_pool.get();
autogc_tracked_object = arr_pool.get();
s.arr = gc_tracked_object.arr;
returns;
}
// TODO: Recycle the struct and object again to their pools// again when this S struct item is removed from malloc map.
}
Boost Software License Version 1.0. See LICENSE_BOOST.txt for details.
Alternatively, this file may be distributed under the terms of the Tango
3-Clause BSD License (see LICENSE_BSD.txt for details).
Base class for a bucket element allocator using malloc function bypassing the GC.
By default the class constructor checks the type of the Bucket elements (i.e, the values stored in the Map). If the element contains reference items (e.g class or an array) then on malloc allocations the class adds the elements to the GC scan range and removes them from the GC scan range on recycling.
This tracking of the objects can be explicitly disabled through passing the appropriate flag to the class constructor.
Warning :
Do not disable the tracking of the allocated elements except if the element if there is another reference to the GC allocated items elsewhere.
The following is a more detailed explanation about what's safe to store without GC tracking and what's unsafe.
If the elements stored in the map (i.e the struct or class you are storing) contains a GC managed memory item and the single reference to this memory is only in this malloc-based map then the GC will collect this data as no other GC object is referencing it. Once collected you will end up with segmentation fault when you to access this non-used memory address.
For example, consider that what you are storing in the map is the following :
This reference items doesn't have to be added to the GC scan list if it has another reference in the GC (e.g when another reference exists in a pool).
For example: