Re: JavaMemoryModel: Implementing atomic object creation on Alphas may be cheap

Date: Wed Oct 13 1999 - 14:29:31 EDT

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.


JavaMemoryModel mailing list -

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