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 Wed, 28 Feb 2007 04:44:32 GMT
On second thought, the only way I know to implement volatile long (64-bit)
Java variables on ia32 is:

grab critical section
mov [ecx], low32bits;   // to do a write, the code for doing a read is
similar
mov[ecx+4], hi32bits;
release critical section

Some observations:
1)
Fixing the "volatile long" bug (Harmony-2092) by using critical section as
above should, as a side-effect, allow DekkerTest.java to run.
2)
Using volatile long sort of, kind of defeats a major reason to use Dekker
algorithm in the first place.  Why bother if the performance is the same as
using critical sections?
3)
Using "volatile int" in DekkerTest.java probably still fails because reads
can pass writes.  One way to fix this might be to make the JIT emit r/w
memory fence whenever reading/writing the volatile int.  While memory fences
are often cheaper than HW locks, they are not free.
4)
My guess is that there are no old legacy Java apps that use Dekker
algorithm.  In other words, nobody is dependant on Dekker algorithm
working.  My guess is that they are, however, dependent on volatile long and
volatile int working properly. (which has the side effect of making Dekker
algo work.)


On 2/21/07, Weldon Washburn <weldonwjw@gmail.com> wrote:
>
>
>
> 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
>



-- 
Weldon Washburn
Intel Enterprise Solutions Software Division

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