harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Egor Pasko <egor.pa...@gmail.com>
Subject Re: [testing] Reliability test suite is contributed, HARMONY-2918
Date Tue, 02 Jan 2007 12:17:37 GMT
On the 0x251 day of Apache Harmony Weldon Washburn 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). 

why? In JIT we cancel "Common Subexpression Elimination"-like
optimizations for volatile variables, which sould be enough for now.

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

Weldon, interesting idea! But DekkerTest2.java will not necessarily
fail, especially for JET because JET almost does NOT optimize memory
accesses. That makes me think DekkerTest2.java would show us how
DekkerTest is good at testing OPT. But... DekkerTest2 would NOT be
suitable for regular runs.

Alternative idea to check 'volatile' goodness in OPT: comment out all
volatile checks in Jitrino.OPT's sources. You will see how real
multithreaded apps like Eclipse fail to work without special
'volatile' handling (we call it memory fences).

Egor Pasko

View raw message