harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Fedotov" <alexei.fedo...@gmail.com>
Subject Re: [drlvm]kernel test
Date Tue, 28 Nov 2006 07:21:50 GMT
Elena,

It's nice to hear that you are making progress in running kernel tests
iteratively. There is a parallel thread which discusses how we should
integrate ability of iterative test runs into Harmony [1].

Both class library tests and kernel tests use <junit> ant task to run
tests, so I cannot see a problem to create a common solution for both
test suites. Could you please take a look and share your preference
for one of three proposed approaches?

1. http://mail-archives.apache.org/mod_mbox/harmony-dev/200611.mbox/%3cc30d70960611270634p5421315dm1b422ca086a550ae@mail.gmail.com%3e

-- 
Thank you,
Alexei



On 11/27/06, Elena Semukhina <elena.semukhina@gmail.com> wrote:
> On 11/28/06, Alexei Fedotov <alexei.fedotov@gmail.com> wrote:
> >
> > Elena,
> > As far as I understand from your letter the implementation is still to
> > be fixed. Could you please file a JIRA about it?
>
>
> I'm not sure that the implementation is to be fixed as it does not
> contradict the spec for now :)
> Possibly we should fix the test so that it waits e.g. 10% less. Anyway, I've
> filed http://issues.apache.org/jira/browse/HARMONY-2204 some time ago for
> this problem. The patch I suggested is invalid because the test continues
> failing with new timing numbers (I gave 1 ms of freedom but this was not
> enough).
>
> Geir,
> > As for the best of my knowledge there are no reliability runs for
> > kernel tests. This case proves that trying to run these tests in a
> > loop, especially in one JVM could be useful for detecting new
> > implementation flaws.
>
>
> It is me who runs these tests iteratively for the last week. The runs proved
> that ThreadTest fails sporadically on waiting in join() and sleep() methods
> on Windows and in yield() on linux. I'll file aJIRA issue for the latter.
>
> Thanks,
> Elena
>
> --
> > Thank you,
> > Alexei
> >
> >
> > On 11/27/06, Elena Semukhina <elena.semukhina@gmail.com> wrote:
> > > On 11/28/06, Elena Semukhina <elena.semukhina@gmail.com> wrote:
> > > >
> > > > The problem with ThreadTest has not been fixed yet. I'm running this
> > test
> > > > iteratively now to see the sporadic failures. Indeed,
> > testJoinlongint()
> > > > fails rather often. The spec for join() reads that it should wait at
> > most
> > > > millis milliseconds for this thread to die. But the thread which is
> > > > joining in the test does not stop
> > > >
> > >
> > > The obvious typo: I meant "the thread which is joined".
> > >
> > >
> > >  running. Can we allow join() to exit earlier in this case?
> > > >
> > >
> > > I modified the test so that to let join() wait  for10 ms less (which
> > > is 0.5%of waiting time) and ran it again iteratively. It failed once
> > > with 1972 ms
> > > of waiting!
> > >
> > > I looked through RI's bug database for relevant issues and found the
> > > following:
> > >
> > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4132653
> > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5068368
> > >
> > > The last comment of the latter says that the spec will be fixed in Java
> > SE
> > > 6.0!
> > >
> > > BTW, the test always passes on linux for me.
> > >
> > > Thanks,
> > > Elena
> > >
> > >
> > > > On 11/28/06, Rana Dasgupta <rdasgupt@gmail.com> wrote:
> > > > >
> > > > > I may have missed it, it's  very possible, could someone point me
to
> > the
> > > > > fix
> > > > > or the thread ? My comments are based on what's in Harmony drlvm
> > trunk
> > > > > as of
> > > > > a few hours ago.
> > > > >
> > > > > Thanks,
> > > > > Rana
> > > > >
> > > > >
> > > > > On 11/27/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
> > > > > >
> > > > > > I thought this exact problem was identified and already fixed...
> > > > > >
> > > > > > geir
> > > > > >
> > > > > > Rana Dasgupta wrote:
> > > > > > > Hi,
> > > > > > >   On Windows XP, java.lang.ThreadTest ( testJoinlongint
> > component )
> > > > > > keeps
> > > > > > > failing for me sporadically. Debugging this, I saw that
the
> > problem
> > > > > was
> > > > > > > with
> > > > > > > the expiry interval on thread.join(millis, nanos ). Tests
based
> > on
> > > > > timed
> > > > > > > waits are somewhat unpredictable on most platforms.
> > > > > > >  In condvar_wait_impl(), we seem to set up the timeout
interval
> > in
> > > > > > > microseconds before calling apr_thread_cond_timeout().
On
> > Windows,
> > > > > > > apr_thread_cond_timeout() implements using WaitForSingleObject(
> > > > > event,
> > > > > > > timeout )....but the Windows timeout is in milliseconds,
as far
> > as I
> > > > >
> > > > > > know.
> > > > > > > Is this not an error, or am I missing something? I did
not want
> > to
> > > > > > change
> > > > > > > anything since condvar_wait_impl() is on the code path
of
> > several
> > > > > timed
> > > > > > > waits.
> > > > > > >  Also, on a less important note, the tests testJoinLong()
and
> > > > > > > testJoinLongint() seem to test to see that the thread.join
> > (milli,
> > > > > nano)
> > > > > > > timeout is "at least" equal to the specified interval.
My
> > > > > understanding
> > > > > > is
> > > > > > > that this should be "at most" the specified interval. Any
ideas?
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Rana
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Thanks,
> > > > Elena
> > >
> > >
> > >
> > >
> > > --
> > > Thanks,
> > > Elena
> > >
> > >
> >
> >
> > --
> > Thank you,
> > Alexei
> >
>
>
>
> --
> Thanks,
> Elena
>
>

Mime
View raw message