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 16:19:52 GMT
On 11/17/06, Gregory Shimansky <gshimansky@gmail.com> wrote:
>
> Elena Semukhina wrote:
> > 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
>
> Yes it can. But I think that comparison at the end of the test that
> "finish - start + 1 > millis" mean that it should be 1 more millisecond
> of waiting. To do this it was intended to wait for 500 and a half =
> 500.5 milliseconds, which means that nanos should be 500000, not 500.
>
> Correct my if I am wrong about the original test intension.


I'm not an author of the test but I think we should wait one more
millisecond even if we ask to wait 500.0005 ms because a millisecond is a
minimal available time unit. I expect that the time is rounded up rather
than towards the nearest vlaue. Am I wrong?

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


-- 
Thanks,
Elena

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