I quite agree that the finalization model needs to be as intuitive as
possible and don't believe that in most cases programmers should need to
put explicit synchronisation into the finalize method to get the behaviour
they expect; that the results of operations done in the methods of a class
are available to the finalize method of that class. I previously appended
the following to the discussion but nobody has commented further. I
believe that most if not all existing JVMs do the right thing and that we
should at least specify as much in JSR133.
------- previous append ------------
I have been re-reading the discussion on finalizers. The general trend of
the discussion is that all finalizers should be synchronized since they can
be run on a separate thread. I don't believe that for most usages and most
(if not all VMs) that rule is actually correct. The process of identifying
objects to be finalized actually has the effect of ensuring that the GC
thread (whichever that is) is guaranteed to have seen the last write to the
object at the point that it realises that there are no remaining strong
references to the object. So, does the GC thread pass on that guarantee to
the finalizer thread ? I believe that in current VMs it does since the
process involves a monitor controlling a list of to-be-finalized objects.
If the VM chose to employ some atomic operation not involving memory
barriers then of course the guarantee would not be passed on. However, in
general a single monitor operation will perform much better than many
atomic operations and thus I believe that current VM's would have no
problem in making the guarantee that a finalizer will behave as if there
existed a 'finalization lock' on the object. This lock is released after
the last update of the object and obtained by the finalize method. For a
large class of users this guarantee would be all they needed to avoid them
worrying about synchronization simply as a consequence of the VMs decision
to employ a separate finalizer thread.
--- end of previous append ---------
I think I'm right in saying that the proposal is to add the guarantees that
you are looking for to Thread.join etc. That's already a part of JSR 133.
Martin Trotter
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:44 EDT