harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [drlvm][reliability tests] Harmony-2986, Dekker's algorithm -- is this a valid test for modern SMP hardware?
Date Thu, 22 Feb 2007 00:43:58 GMT
On 2/21/07, Gregory Shimansky <gshimansky@gmail.com> 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 <weldonwjw@gmail.com> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message