Hans Boehm wrote:
> What I don't like it about is that it introduces a shared and frequently
> written static field. How the performance compares to the empty
> synchronized block is unclear to me. If the volatile write misses
> the cache most of the time, because another processor wrote it last (not
> unlikely), and I have to wait for completion of the write (perhaps
> not unlikely because of the second volatile write), this is potentially
> appreciably slower than the empty synchronized block.
>
> (I would guess that the empty synchronized block costs 15-400 cycles
> on a modern processor, depending on the platform. The cache miss is
> probably closer to the high end of that on all modern machines,
> especially large SMPs.)
I guess that there are a couple of other things the user can bear in mind:
1) For many of the use cases of finalizers (I/O classes, for example),
the cost of performing a keepAlive (in any form, whether it be
volatiles, writing a reference to the heap, or empty synchronization) is
swamped by the cost of actually performing the task.
2) If performance is critical, the programmer can limit the invocations
of keepAlive to the client code; thus, in the cases where you don't need
keepAlive (all those in which a reference to the object is written out
to the heap), it doesn't get called.
This second thing may not be good for many libraries, but there are few
enough of them with finalizers that it may work.
Jeremy
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:01:10 EDT