www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - New memory management strategy

reply Axe <meowd99 yahoo.in> writes:
Hi there. I have found a new memory management strategy based on 
whole program lifetime inference.

Disclaimer: I am no expert and hence what follows may be 
completely wrong or impractical. So bear with me.

The first step is to construct an "escape" lists for each and 
every function.
Escape list stores all the lvalues that may escape, while all 
other lvalues are released when the scope ends.

Foo get(Baz baz)
{	
	Bar bar;
	baz.bar = bar; // 'bar' escapes into field 'bar' of 'baz' which 
is the argument.
} // Escape list consist of 'bar'. Every field of 'baz' except 
baz.bar is freed.

int main()
{
	Baz baz; // Scope depth is 1.
	get(baz); // From the already built escape list for 'get', we 
can infer
			  // that baz.bar escapes to call-site's scope depth 1.
} // baz is eventually released here.

Since we cannot find the control flow path in a function. All the 
variable
declarations are moved to the top of the function, so that 
control flow doesn't determine whether
the variables are allocated or not.

Now the question is whether this is correct/practical or not?
Jun 24 2017
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Sunday, 25 June 2017 at 05:29:02 UTC, Axe wrote:
 Since we cannot find the control flow path in a function. All 
 the variable
 declarations are moved to the top of the function, so that 
 control flow doesn't determine whether
 the variables are allocated or not.

 Now the question is whether this is correct/practical or not?
Backends generally do things like this, i.e. reusing locations on the stack when the variables on it are no longer alive, although you don't actually have to stack allocate anything when you don't call other functions since then you don't have to figure out how much space you need on the stack. So you can just use the whole stack as a scratchpad if you want to. https://en.wikipedia.org/wiki/Live_variable_analysis
Jun 24 2017