Weldon,
I've looked at suggested DekkerTest.
I think that k < 100000 should be eliminated. Thanks for pointing it out.
Also I think that test instability root cause is volatile array usage, which
should be replaced by volatile variables.
I've attached another version of DekkerTest.java to
http://issues.apache.org/jira/browse/HARMONY-2918
This test intermittently hangs on drlvm, see
https://issues.apache.org/jira/browse/HARMONY-2986
for detailes.
Thanks,
Tanya
On 1/2/07, Weldon Washburn <[EMAIL PROTECTED]> wrote:
On 1/2/07, Oleg Oleinik <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
> > On 12/28/06, Oleg Oleinik <[EMAIL PROTECTED]> 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
