harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oleg Oleinik" <oleg.olei...@gmail.com>
Subject Re: [testing] Reliability test suite is contributed, HARMONY-2918
Date Tue, 02 Jan 2007 10:50:53 GMT
> 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.


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
>
>

Mime
View raw message