Stale Pointer access through Escape Analysis?

Hello, All,

the following problem most likely applies to manual memory
management (a.k.a. malloc/free), but it may also apply to
any GCed system that uses some form of program analysis
(in particular, escape analysis) with the goal of relieving
the GC from some work.  It /may/ even apply to the latter
systems more than to the former.  From this observation, I
take the chutzpah to post it to gclist :)

First of all, it seems sensible to require that an object
remain allocated while there are accesses to it.  However,
operations like comparing to pointers, or passing a
pointer into a function as a parameter or out of a function
as the return value do not require the object to remain
allocated.  Only object allocation, and writing into objects
and reading values out of objects (and possibly, doing
virtual method calls 'on' an object) require the object to
be allocated.

Consider the following code, written with either GC and and
some escape analysis, or written using malloc/free:
Suppose that the escape analysis or the programmer decides
that in the following code, the object pointed to by 'a'
needs to be allocated from point (1) to point (2):

(1) Foo a = new Foo ();
     a.foo ();
     aVariable = a.aField;	// access to a
(2) delete a;

(3) Foo b = new Foo ();
(4) if (a == b) {		// not an access to a
       b.afield = aValue;
     }

In line (3), the heap memory manager /might/ allocate 'b' at
the same address as 'a' (which, since line (2) is now free),
therefore making the comparison in (4) evaluate to 'true'.

If only a run-time GC had been used, (2) wouldn't exist, and
'a' would have kept its object reachable at (3), thereby ensuring
that (4) would always evaluate to 'false'.

Of course, the code above is contrived, but a few hasty changes
to a software system with a deadline coming up soon might lead
a developer to write this kind of code.  Also, even if the code
is contrived, a compiler optimization should not depend on the
code it optimizes to make sense in any particular way.

Now, in all works on Escape Analysis I've seen so far, none of
them addresses this problem.  Did I miss something?  Or would it
be sensible to dismiss this problem, arguing that the chances
of it happening in practice are so low?  Can anyone elaborate on
how often this happens when manual memory management is used?

cheers,
Florian Liekweg

--