Gabriele Svelto (gabriele.svelto@gmail.com) on 10/20/06 wrote:
>So in the case of a processor with out-of-order store visibility
>you will probably need to add a memory barrier at the exit point of every constructor
>or before the first time you copy the new object reference to memory. A JVM failing
>to do so should be considered not complaint with the SPEC and thus buggy.


Exactly (btw, thanks for the in-depth explanation!). I am not arguing that the JVM is broken (obviously this isn't a problem on x86 anyway), but that all implementations of any safe language in a multi-threaded environment have to potentially suffer a penalty on every alocation. This was a shocking realization, at least to me.

I can't judge how serious this penalty is. On x86 it is none. Which of the other non-dead platforms (PPC, Itanium, Sparc?) have relaxed memory ordering and would be affected ?

Obviously the future of computing is multi-threading, and it at least seems that safe languages are a big part of that future too. It appears that there is at least some impedance mismatch between the two. It also logically follows that the only architecture perfectly suited for the future is x86 :-)