Memory Safety without a GC or Ref Counting

H. S. Teoh hsteoh at quickfur.ath.cx
Mon Jan 21 17:37:02 PST 2013


On Mon, Jan 21, 2013 at 11:36:58PM +0100, Paulo Pinto wrote:
> Am 21.01.2013 22:25, schrieb H. S. Teoh:
[...]
> >Hmm. So you're essentially saying that the compiler will do
> >compile-time analysis of variable usage, and based on that choose the
> >simplest memory management model for it?
> >
> >That's not a bad idea. You can have a series of increasingly complex
> >management techniques, and the compiler could choose the least
> >complex one that it can statically prove is safe. So if something can
> >be proven not to escape the current scope, it can even be
> >stack-allocated (or if it's big, put it on the manual heap and delete
> >it on scope exit). If it is returned with no other references to it,
> >then it can be a single-reference pointer (i.e. your owner type). If
> >it has cyclic references, use a reference-counted pointer. If all
> >else fails, fall back to the GC.
> >
> >The problem is that quite often, the compiler will not be able to
> >prove much about the data structure, esp. when you have non-trivial
> >manipulation of pointers -- it requires solving the halting problem
> >to achieve that level of analysis on arbitrary code -- so it will
> >probably fall back to the GC quite often, depending on what the code
> >does.
[...]
> I see how this could work in a JIT environment, but not in a static
> compiler with modules compiled in separate ways.
[...]

It can be made to work with separately-compiled modules if there's
language support (say in the form of exported pointer attributes). But
probably not feasible in the current version of D.


T

-- 
Designer clothes: how to cover less by paying more.


More information about the Digitalmars-d mailing list