I am experiencing errors in the IBMJava2 1.4.2 JIT compiler on a SLES9
SP3 system related to the shift operator. I believe this to be an error
in the JIT compiler since there are no errors if the same Java program
runs uncompiled. What happens is that the Java unsigned right-shift
operator ( >>> ) produces incorrect results - the first 1600 or so
iterations produce correct results, and then it produces incorrect
results afterwards.
Here is the Java code that is effected by the problem:
public Object produce(TDPacketStream stream, boolean nullValue)
throws SQLException { //DR88402, DR104370
// DR68391-lucy Add comments here to explain changes due to
prepInfoX
// DECIMAL(10,4) in a prepInfo parcel: length is 0x0a04
// DECIMAL(10,4) in a prepInfoX parcel: length is
0x0000000a00000004
// The shiftBits value tells how far to shift to get the length
// We now always get a long length to do the calculations
// e.g. either 0x0000000000000a04 or 0x0000000a00000004
BigInteger bvalue = null; // DR95968
Long value = null;
long len = getLongDataLen(); // DR68391-lucy: get 64
bits for length
precision = (int) (len >>> shiftBits); // shift 8 or 32 bits
scale = (int) (len & 0x7f); // last 2 bytes have
scale
log.debug ("PrepInfoItemDecimal.produce: len=" + len + " shiftBits=" +
shiftBits + " precision=" + precision + " scale=" + scale) ;
if (precision <= 2) {
value = new Long(stream.get());
} else if (precision <= 4) {
value = new Long(stream.getShort());
} else if (precision <= 9) {
value = new Long(stream.getInt());
} else if (precision <= 18) { //DR88402
value = new Long(stream.getLong());
} else if (precision <= 38) { // DR95968
bvalue = stream.get16ByteBigInteger(); // DR95968
} else {
log.debug ("PrepInfoItemDecimal.produce: Unexpected
DECIMAL precision: len=" + len + " shiftBits=" + shiftBits + "
precision=" + precision + " scale=" + scale) ;
throw ErrorFactory.makeDriverJDBCException("TJ373",
precision); //DR88402
}
if(bvalue == null) // DR95968 - start
return nullValue ? null :
BigDecimal.valueOf(value.longValue(), scale);
else
return nullValue ? null : new BigDecimal(bvalue, scale); //
DR95968 - end
}
Here is an excerpt of the log produced by our JDBC Driver. The important
point is that the data values 77309411333 and 21474836480 are correctly
shifted right for about 1600 iterations, and then, all of a sudden, the
same data values 77309411333 and 21474836480 are shifted right
incorrectly.
Thousands of log entries like these, showing the correct results:
2006-10-23.12:05:28.738 TERAJDBC4 DEBUG [main]
[EMAIL PROTECTED] PrepInfoItemDecimal.produce:
len=77309411333 shiftBits=32 precision=18 scale=5
2006-10-23.12:05:28.738 TERAJDBC4 DEBUG [main]
[EMAIL PROTECTED] PrepInfoItemDecimal.produce:
len=21474836480 shiftBits=32 precision=5 scale=0
2006-10-23.12:05:28.739 TERAJDBC4 DEBUG [main]
[EMAIL PROTECTED] PrepInfoItemDecimal.produce:
len=77309411333 shiftBits=32 precision=18 scale=5
2006-10-23.12:05:28.739 TERAJDBC4 DEBUG [main]
[EMAIL PROTECTED] PrepInfoItemDecimal.produce:
len=21474836480 shiftBits=32 precision=5 scale=0
2006-10-23.12:05:28.740 TERAJDBC4 DEBUG [main]
[EMAIL PROTECTED] PrepInfoItemDecimal.produce:
len=77309411333 shiftBits=32 precision=18 scale=5
2006-10-23.12:05:28.740 TERAJDBC4 DEBUG [main]
[EMAIL PROTECTED] PrepInfoItemDecimal.produce:
len=21474836480 shiftBits=32 precision=5 scale=0
2006-10-23.12:05:28.741 TERAJDBC4 DEBUG [main]
[EMAIL PROTECTED] PrepInfoItemDecimal.produce:
len=77309411333 shiftBits=32 precision=18 scale=5
2006-10-23.12:05:28.741 TERAJDBC4 DEBUG [main]
[EMAIL PROTECTED] PrepInfoItemDecimal.produce:
len=21474836480 shiftBits=32 precision=5 scale=0
Then the right-shift operator ( >>> ) produces incorrect results:
2006-10-23.12:05:28.862 TERAJDBC4 DEBUG [main]
[EMAIL PROTECTED] PrepInfoItemDecimal.produce:
len=77309411333 shiftBits=32 precision=-1879048192 scale=5
2006-10-23.12:05:28.862 TERAJDBC4 DEBUG [main]
[EMAIL PROTECTED] PrepInfoItemDecimal.produce:
len=21474836480 shiftBits=32 precision=0 scale=0
Any help would be appreciated. If the JIT compiler needs a fix, who do I
contact to get this fixed?
----------------------
Judson West
Systems Programming Team
Teradata(r), a division of NCR Corporation
All words above are not actual sentences but random letters, spaces and
the occasional punctuation. I can not be held responsible for the
meaning you get from these random letters. I can however be held
responsible for the spaces.
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
