david.holmes at oracle.com
Mon Nov 7 01:05:23 UTC 2011
On 4/11/2011 11:36 PM, Gary Adams wrote:
> I've started to look at timing related bugs that have been open
> for a while, but have not had sufficient priority to make it to the
> top of the list of bugs to be fixed. Thought I'd start with some
> low hanging fruit with simple bug fixes.
Sometimes apparently low-hanging fruit is attached to the tree with
steel wire ;-) (and sometimes barbed wire at that)
> 6731620: TEST_BUG: java/util/Timer/Args.java is too optimistic about the
> execution time of System.out.printf
> This seems like a simply problem to avoid two calls to get the current time
> and to eliminated the time to process the print statement
> from the evaluation of the test elapsed time.
> Replacing this sequence ;
> System.out.printf("elapsed=%d%n", System.currentTimeMillis() - start);
> check(System.currentTimeMillis() - start < 500);
> elapsed = System.currentTimeMillis() - start;
> System.out.printf("elapsed=%d%n", elapsed);
> check(elapsed < 500);
This seems reasonable on the face of it. But a couple of other
observations regarding the test code:
First the 500 is somewhat arbitrary - the test is preparing three
timertasks with initial expiry times in the past and expecting them to
all execute "immediately" (one multiple times). This immediacy is
translated into "completes within 500ms". These type of timing constants
should be eradicated if possible, or preferably made configurable if
not. It is a difficult problem to address if you want to try and detect
something taking an unexpectedly long time, but have no idea what your
execution environment will be.
Second, the current code won't detect a true failure that results in a
hang - the testcase will hang and presumably get timed-out by the test
harness. It might be better to apply a timeout to the await() calls
instead and fail only if they do timeout.
Third, in this case it would also be prudent to (re-)read the start time
after the setup has been done ie after creating the countDownLatches. If
this is run in samevm mode or agentvm mode those constructions may
trigger a full GC and the ensuing delay could cause the test to again fail.
That all said, I'd see combining your suggested fix with moving the
point at which start is measured as definite improvements in the test.
> I plan to test the fix on a 300MHz linux/arm device.
> I'll provide a proper webrev as soon as I have author rights
> confirmed. I'm looking for reviewer and a committer,
> once I get the fix tested locally.
I presume by "committer" you mean somebody to actually do the push for
you - I think we generally refer to that as a "sponsor" (even though not
part of OpenJDK terminology). In any case that should be someone from TL
group and I'll let them respond further on that and provide any
additional review comments.
I'm happy to act as another Reviewer.
> Gary Adams
More information about the core-libs-dev