harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [testing] Reliability test suite is contributed, HARMONY-2918
Date Tue, 02 Jan 2007 15:08:47 GMT
On 1/2/07, Oleg Oleinik <oleg.oleinik@gmail.com> wrote:
>
> > while (current != worker && k < 100000) {k++;}
> > The burning question is why was the "k < 100000" test added?
>
> Look like "k<100000" is added to avoid test hanging, looks like it
> should be removed. Let me think more.


I also suspect the "k<1000000" was added to avoid test hanging.  If the
test does, in fact, hang when "k<1000000" is removed, we have a whole new
set of problems to deal with.  It could be the case that this test
"reliably" passes with a known race condition.  In other words, this test
may indicate bugs in the test as well as the JVM.  My experience is that
these kinds of issues can be very difficult and time consuming as they
involve the hardware's memory consistency model as well as the software
running on top.

On 1/1/07, Weldon Washburn <weldonwjw@gmail.com> wrote:
> > On 12/28/06, Oleg Oleinik <oleg.oleinik@gmail.com> wrote:
> > >
> > > Hi,
> > >
> > > Reliability test suite is contributed on behalf of Intel:
> > >
> > > http://issues.apache.org/jira/browse/HARMONY-2918
> > >
> > > The tests are intended to verify ability of the runtime to run
> > > successfully for long time. The suite contains 72 tests (covering
> > > mainly kernel, nio, text, io, net, zip classes functionality, plus a
> > > couple of tests for VM) and ant scripts to build and run tests.
> > >
> > > The tests are intented to be integrated into buildtest/. Please review
> > > and comment.
> >
> >
> > This is great.  These are much needed tests.
> >
> > I have started looking at the tests and have questions about
> > kernel/thread/VolatileVariableTest/DekkerTest.java.
> >
> > regionIn() corresponds to the part of the Dekker algorithm that acquires
> the
> > critical section.  regionIn() contains code that, as far as I can tell,
> is
> > not part of the Dekker algorithm.  regionIn() spins for 100000 loops
> then
> > assumes/pretends the critical section has been acquired (??).  The line
> of
> > code I refer to is:
> >
> > while (current != worker && k < 100000) {k++;}
> >
> > From reading the Dekker algo reference, it seems this line of code
> probably
> > should be:
> >
> > while (current != worker) { }
> >
> > The burning question is why was the "k < 100000" test added?
> >
> > At the top of DekkerTest.java it says, "Goal: check that VM supports
> > volatile variables".  My guess is that the JIT must put memory fence(s)
> > around volatile variable reads and writes.  My guess is that Dekker is
> > probably one of the few ways to actually test for proper implementation.
> > But I really worry that the JIT could accidentally miss emitting the
> memory
> > fence(s).  And DekkerTest.java would pass anyway.  Does it make sense to
> > create "DekkerTest2.java" that is identical to DekkerTest.java where all
> the
> > "volatile" kepwords are omitted?  The intention is to create a test that
> > will hard fail if the memory fences are not emitted.
> >
> >
> > Best regards, Oleg
> > >
> >
> >
> >
> > --
> > 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