[Since no one complained last time, I'm going to paraphrase again.]
>> David Holmes stated: "Why are we looking at implementations of
>> loads of vtable pointers on relaxed-order machines? As interesting
>> as this may be, it seems off-topic for this list."
> Bill Pugh responded: "If we can find a good solution to solving this
> problem, then maybe we can find a good relaxed-order implementation
> of the synchronization-free initialize-then-publish idiom."
While Bill's response is well taken, I don't believe this thread is
going to be productive. David Holmes pointed out that that the
solutions tend to depend heavily on architectures, particular
implementations of architectures, and even on OS features. Having
watched Sanjay struggle with these kinds of problems for several years
now, I can attest to this fact. Further, you never know how good a
solution is until you implement them and measure them. Thus, the best
we can hope for in this discussion is some hand-wavey solutions of
untested quality -- not very helpful.
Bill's suggested at some point we keep the scope of this discussion to
an exploration of high-level pro's and con's of different JMM
semantics so that we can provide useful information to the decision
makers who will be changing the JMM semantics. In keeping with this
suggestion, perhaps we could try to find a high-level conclusion to
this thread to which we can all agree. I propose the following:
The more ordering constraints there are in the JMM semantics, the
harder those semantics will be to implement on relaxed-order
architectures such as Alpha, PowerPC, and IA-64. This observation
primarily affects two requirements being considered for the JMM
semantics: that the JMM semantics preserve Java's safety guarantees,
and that the JMM semantics support the synchronization-free
initialize-then-publish programming idiom. There's clear consensus
that preserving the safety guarantees must be a requirement, no
matter the difficulties that requirement poses on relaxed-order
architectures. There is no consensus on whether the
initialize-then-publish idiom is so important that it must be
supported despite the implementation difficulties it poses on
This is the JavaMemoryModel mailing list, managed by Majordomo 1.94.4.
To send a message to the list, email JavaMemoryModel@cs.umd.edu
To send a request to the list, email email@example.com and put
your request in the body of the message (use the request "help" for help).
For more information, visit http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:14 EDT