Re: Stale Pointer access through Escape Analysis?

Florian Liekweg wrote:

> 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?


"safe-for-space", sorta.

http://lists.tunes.org/archives/gclist/1997-April/001197.html


Regarding your original code:

(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
(5)      b.afield = aValue;
    }


Don't write code like that if the correctness of the
code depends in any way at all on whether or not
the object once referenced by 'a' is live or dead or
finalizer-reachable or in any other state at line (5).
Even in a reasonable safe-for-space GC system you can say
pretty much nothing about the status of 'a' at (5).
You may as well think of the test at (4) as a random
bit generator, albeit one likely to have a strong bias
in any specific system.

I wouldn't dismiss the problem.   In any GCed system
whether safe-for-space or not the outcome of the test at (4)
tells you *nothing* about whether the object referenced by
'a' has been reclaimed or not.   (If we looked at more of
the compilation unit then it might be the case that we could
say something definite about the status of the 'a' object
at (4) but that's the point -- we'd have to look at more of
the compilation unit.)    An ideal 'lint(1)' program would
flag (4) as probably a programming error.  But I repeat
myself.

Come to think of it, even in an explicit memory mgt. system,
without seeing more of the compilation unit, I *still* can't
say anything about whether the memory for 'a's object has
been reclaimed by (4).   This is extremely unlikely to actually
come up, outside of the implementation of 'malloc', but it
is still what the semantics say.

Close-in-time re-use of explicitly managed regions of
memory is common.  (Good thing, too.)

Errors resulting from space-leaks from not-safe-for-space
GCs are a matter of at least *some* controversy.   I've
seen them happen enough in my own code to want either
a safe-for-space guarantee or a scope-defines-traceability
guarantee and despise everything in between.    Yet most
popular systems are in between and I'm a minority voice
in complaining.   (My suspicion is that (a) most accidental
space leaks don't matter;  (b) black-hats haven't yet got around to
triggering space-leaks on purpose.)

Oh, by "scope-defines-traceability" I mean, for example,
that at (4) the object referred to is certainly still live because
'a' refers to it.   If I break into a debugger and inspect the
value of 'a', I reliably expect to see the object.

-t