harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "tatyana doubtsova" <tatyanadoubts...@gmail.com>
Subject Re: [testing] Reliability test suite is contributed, HARMONY-2918
Date Fri, 12 Jan 2007 15:42:30 GMT
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 <weldonwjw@gmail.com> wrote:
>
> 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