On 2/21/07, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
On Wednesday 21 February 2007 21:47 Rana Dasgupta wrote: > Weldon, > But I am not sure why the behavior would be different from J9 on the same > hardware. Do we jit volatiles differently?
The differences in behavior can be caused by lots of things that are not related to memory model. For example the JIT might actually emit slighly different code. Slighly different code can easily open/close race conditions. The important concept is that both J9 and drlvm fail. And the failure appears to be because modern hardware is most likely not designed to run Dekker's algo without memory fences. There is a bug on DRLVM about volatile variables HARMONY-2092. It is about
long and double type variables assignments. Is it the same as in Dekker's algorithm?
DekkerTest.java uses "long" variables. Yes, this could change the rate of failure but not eliminate failures completely.
On 2/20/07, Weldon Washburn <[EMAIL PROTECTED]> wrote: > > It seems Dekker's algorithm is not expected to work on SPARC or IA32 SMP > > boxes unless memory fences are used. DekkerTest.java in Harmony-2986 > > does not contain memory fences. The volatile keyword guarantees the > > compiler will write a given variable to memory. However, the HW may > > actually have a > > write buffer and allow reads to pass writes. As far as I know, the Java > > language does not provide a means to invoke a memory fence. Thus there > > is no way to fix up DekkerTest.java. I may be misunderstanding something > > here. Does anyone have comment? > > > > An excellent description of the issues involved is in a David Dice > > presentation at: > > > > http://blogs.sun.com/dave/resource/synchronization-public2.pdf > > > > -- > > Weldon Washburn > > Intel Enterprise Solutions Software Division -- Gregory
-- Weldon Washburn Intel Enterprise Solutions Software Division
