Possible quick win in GC?
Abdulhaq via Digitalmars-d
digitalmars-d at puremagic.com
Sun Sep 28 09:29:44 PDT 2014
Perhaps I've too had much caffeine today but I've had an idea
which might give a fairly quick win on the GC speed situation.
It's a simple idea at heart so it's very possible/likely that
this is a well known idea that has already been discarded but
anyway here goes.
I got the idea after thinking that it should be fairly simple for
the compiler to detect straightforward cases of when a variable
can be declared as going on the stack - i.e. no references to it
are retained after its enclosing function returns. At the moment
AIUI it is necessary for a class instance to be declared by the
programmer as 'scoped' for this to take place.
Further, I was considering the type of ownership and boundary
considerations that could be used to improve memory management -
e.g. using the notion of an owner instance which, upon
destruction, destroys all owned objects.
Afer some consideration it seems to me that by using only static
analysis a tree of references could be constructed of references
from a root 'scoped' object to all referred to objects that are
allocated after the allocation of the root object. When the root
object goes out of scope it is destroyed and all the descendent
objects from the root object (as identified by the static
analysis) could also be destroyed in one simple shot. The static
analysis of course constructs the tree by analysing the capturing
of references from one object to another. It could be the case
that even a simple static analysis at first (e.g. discard the
technique in difficult situations) could cover a lot of use cases
(statistically).
Of course, if one of the descendent objects is referred to by an
object which is not in the object tree, then this technique
cannot be used. However, I envisage that there are many
situations where upon the destruction of a root object all
related post-allocated objects can also be destroyed.
In terms of implementation I see this being done by what I am
calling 'bands' within the GC. With the allocation of any
identified root object, a new band (heap) is created in the GC.
Child objects of the root object (i.e. only referred to by the
root object and other child objects in its tree) are placed in
the same band. When the root object goes out of scope the entire
band is freed. This by definition is safe because the static
analysis has ensured that there are no 'out-of-tree' references
between child objects in the tree and out-of-tree (out-of-band)
objects. This property also means that normal GC runs do not need
to add the scoped root object as a GC root object - this memory
will normally only be freed when the scoped root object at the
top of the tree goes out of scope. If memory becomes constrained
then the bands can be added as root objects to the GC and memory
incrementally freed just as with regularly allocated objects.
Sorry if this idea is daft and I've wasted your time!
More information about the Digitalmars-d
mailing list