I think that this may be due to the way that 'compileTime' is computed
in GenericStatement.prepMinion(). During the processing of the statement,
GenericStatement computes the overall time that was taken, and breaks
it down into various phases: parse time, bind time, optimize time, generate time,
and overall compileTime. It does this by calling System.currentTimeMillis() at
various points, and recording the value.
However, I think there is a hole in the current algorithm in which, if the
System.currentTimeMillis clock "ticks" after the line
generateTime = getCurrentTimeMillis(lcc); (line 471)
and before the line
preparedStmt.setCompileTimeMillis(...) (line 521)
then we can have a result where compileTime != (parseTime+bindTime+optimizeTime+generateTime),
which is the invariant being tested by the test.
I think that we may be able to fix this with the following change (not yet tested):
— GenericStatement.java (revision 884222)
+++ GenericStatement.java (working copy)
@@ -521,7 +521,7 @@
bindTime - parseTime, //bind time
optimizeTime - bindTime, //optimize time
generateTime - optimizeTime, //generate time
+ generateTime - beginTime,//compile time
I'm not sure how important or useful these times are, nowadays; modern
processors are so fast, and System.currentTimeMillis is so slow, then
in general the times are always (0,0,0,0).
But I'll experiment with this change, and if it doesn't seem to do any harm,
we can see if it makes this test more reliable.