Bill's scheme looks interesting, but just counting the number
of memory barriers does not give the whole story:
1. The non-null test following a getfield will block until the
load has completed, which could be hundreds of cycles
if the load misses out to memory. Out-of-order machines
will be able to hide some of this latency, but probably
not all.
2. Issuing a memory-barrier immediately after a getfield may cause
bigger stalls than issuing an mb later. For example, this might
happen if the getfield has missed all the way out to memory and
the mb waits for all out-standing loads to complete. I don't
know enough about the current implementations of the Alpha
architecture to know if this is really the case, so take this
point with a grain of salt.
3. Testing for a non-null result from a getfield will require
the introduction of a branch (except on predicated architectures).
That in turn will increase the load on the branch predictor
tables and perhaps result in more mispredictions.
These factors might not be too bad, but its hard to quantify
without running the instrumented code on either a real machine,
or a cycle-level simulator.
Perhaps when I get back from vacation, I can collaborate with
Bill to get real measurements on an appropriately instrumented
version of Compaq's Alpha JVM.
-Sanjay
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:19 EDT