harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Elena Semukhina" <elena.semukh...@gmail.com>
Subject Re: [drlvm][test]Exclude some tests from "build test" target, make 'build test' pass
Date Fri, 17 Nov 2006 14:14:35 GMT
On 11/16/06, Gregory Shimansky <gshimansky@gmail.com> wrote:
> Elena Semukhina wrote:
> > As Gregory mentioned ThreadTest.testJoinlongint() failure he observed
> > yesterday, I filed a http://issues.apache.org/jira/browse/HARMONY-2204
> > issue
> > for that. I saw this failure quite long ago but cannot reproduce it
> today
> > trying different platforms/EMs. When the test failed, it reported that
> > actual wait time is less than required.
> >
> > The spec for join() reads: "Waits at most millis milliseconds plus
> > nanosnanoseconds for this thread to die. " There is an obvious
> > misprint here:
> > there should be "at least" but not "at most" and this was mentioned in
> >
> > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4132653
> > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5068368
> >
> > On the other hand, in classlib ThreadTest I saw that they agree with
> > Thread.sleep(1000)  duration >= 800 and join(100, 999999) duration <=
> 300.
> >
> > Can the current DRLVM guarantee that it does not exit join() earlier
> than
> > expected?
> > If not, we should make the test more tolerable to timing.
> There is also an unstable ObjectTest.testWaitlongint which fails once in
> a while (about once in 50 - 100 runs). It also seems to wait a bit less
> than required. I think there is also a bug in the test, nanos should be
> 500000, not 500. But fixing this doesn't help, test still fails on
> windows.

Gregory, why do you think this is a bug? nanos can be any value between 0
and 999999. Actually there is a bug in thread_native_condvar.c which ignores
any nanos < 1000 when converting them to microseconds.

The spec for Object.wait(long) reads that waiting lasts until:
The specified amount of real time has elapsed, more or less.

It does not say neither "at most" nor "at least". I think we can fix both
tests so that they could wait a little bit less than it is now expected and
print the values at error messages. I attached a patch to HARMONY-2204.
Please take a look and commit if it is OK. Then we can see if the tests
still fail.

I checked the APR function and underlying win API functions, the
> System.currentTimeMillis is measured with microseconds accuracy. The
> Thread.join and Thread.wait end up with WaitForSingleObject function
> which accepts an argument in milliseconds. So I cannot understand why
> the wait/join time is less than required.
> --
> Gregory


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message