> From: Bowen Alpern 784-5487 [mailto:alpern@watson.ibm.com]
>
> As I understand it, the (a) problem is that an object can legally be
> finalized while a method invoked on the object is still running. This
> because the running method might not reference the object
> itself (although
> it might still reference its fields). Is this correct?
Yes. That's part of it anyway.
>
> Would it help to say that an objects is reachable as long as
> any of its
> field may be referenced?
It wouldn't entirely solve the problem, for at least two reasons:
1) It's hard to define "as long as any of its fields may be referenced" precisely, given that the memory model goes out of its way to allow (non-volatile) field references to be optimized, e.g. by reusing previously read values. I think that for this to be really meaningful, the memory model would have to specify separate ordering rules for "last possible reference points", or something along those lines. This sounds really esoteric, even by our standards.
2) In my original example, the data that needed to be accessed before running the finalizer was stored in a separate data structure, outside the object itself. This essentially has to be the case for finalizable objects. If all the relevant data were in the object itself, you wouldn't need a finalizer. (In some cases, e.g. file descriptors, the data may reside outside your address space.)
>
> Synchronization of the method and the finalizer would
> probably still be
> necessary to prevent a race.
In many cases, yes. Do you know if the Jikes RVM has any problems with ensuring that an object is reachable when its lock is released? That still strikes me as by far the simplest solution to this problem.
Hans
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:43 EDT