RE: JavaMemoryModel: Another important finalizer question

From: Boehm, Hans (hans.boehm@hp.com)
Date: Mon Apr 19 2004 - 20:24:32 EDT


Presumably the existing statement is meaningful for final fields in any case.

As I see it, the main argument for the stronger version is that it avoids
having to synchronize constructors, which the syntax doesn't allow. Since
the implementation cost is probably essentially zero, that's not a bad argument.

I agree.

Hans

> -----Original Message-----
> From: owner-javamemorymodel@cs.umd.edu
> [mailto:owner-javamemorymodel@cs.umd.edu]On Behalf Of Bill Pugh
> Sent: Monday, April 19, 2004 3:57 PM
> To: javamemorymodel-cs.umd.edu
> Subject: JavaMemoryModel: Another important finalizer question
>
>
> Consider the following code:
>
> class Foo {
> OutputStream out;
> Foo(File f, byte[] buf) throws Exception {
> OutputStream o = new FileOutputStream(f);
> out = o;
> o.write(buf);
> }
> protected void finalize() throws IOException {
> out.close();
> }
> }
>
> OK, the question is: it is guaranteed that the call to
> o.write completes
> and that all memory accesses that occur during that call happen-before
> any code in the finalizer?
>
> In the spec, we say
> An object cannot be considered finalizable until its
> constructor has
> finished.
> But we do not say that all writes that occur during construction must
> be visible
> to the finalizer.
>
> It really doesn't make sense to have one without the other,
> so I think
> this
> is just tightening things up. Let me know if anyone thinks this needs
> further
> discussion. Otherwise, we'll just clear up the language and adopt it.
>
> Bill
>
> -------------------------------
> JavaMemoryModel mailing list -
http://www.cs.umd.edu/~pugh/java/memoryModel
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel



This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:01:05 EDT