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