On 6/5/06, Ole Solberg <[EMAIL PROTECTED]> wrote:
> On 6/5/06, Ole Solberg <[EMAIL PROTECTED]> wrote: > >> Derbyall >> ******** >> Results from our testing on the 10.2.0.2 snapshots are now available at >> http://www.multinet.no/~solberg/public/Apache/index.html#TenTwoZeroSnapshots >>
I ran derbyall with this 10.2.0.2 snapshot on Linux with a 64bit IBM jvm, versions 1.4.2 and 1.5. With 1.5, I ran once in the default mode, and once with the jit always 'on' (-Xjit:count=0). Looking at our nightly testing with 32 bit jvms on windows it does not seem likely additional trouble will be found with the updated snapshot, so I'm not redoing that testing, but posting the findings here. Issues encountered were either jvm or test harness related (with one possible exception): ================ ibm.1.4.2 - with ibm1.4.2, minor issue regarding wording of security permissions errors; 'Access' vs. 'access' in Sun jvms. I've been told this is a known issue with the jvm vendor. We could add sed-ing to the tests affected so this doesn't show up anymore... - hang in unit/cacheService.unit with ibm1.4.2 64 bit jvm only I need to further analyze this. ibm1.5 - IBM jvm 1.5. JIT causes incorrect results in calculations, leading to very large numbers. This can be seen for instance in the results from runtimestatistics (see also DERBY-1221) or result in too big identity column numbers (see DERBY-1327). The issue has been reported to the jvm team and preliminary info indicates both these behaviors have the same underlying jit problem. This issue is not limited to the 64bit jvm. - derbynetmats testing fails because of an extra jvm line getting generated when calling the db2jcc code: > JVMJ9VM034E jvmri requires trace engine: run with -Xtrace flag This issue has been reported to the jvm vendor/developers. This behavior is specific to 64 bit jvms. - IBM 1.5. jvm is more aggressive in garbage collecting, resulting in fewer error conditions encountered. This has been reported to the jvm vendor/developers. Env Details: ========= host: 2.6.9-34.ELsmp #1 SMP Fri Feb 24 16:56:28 EST 2006 x86_64 x86_64 x86_64 GNU/Linux jvm: 1.4.2: ----------------------- java version "1.4.2" Java(TM) 2 Runtime Environment, Standard Edition (build 2.2) IBM J9SE VM (build 2.2, J2RE 1.4.2 IBM J9 2.2 Linux amd64-64 j9xa64142-20050609 (JIT enabled) J9VM - 20050524_1742_LHdSMr JIT - r7_level20050518_1803) ----------------------- 1.5: ----------------------- java version "1.5.0" Java(TM) 2 Runtime Environment, Standard Edition (build pxi32dev-20060511 (SR2)) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Linux x86-32 j9vmxi3223-20060504 (JI T enabled) J9VM - 20060501_06428_lHdSMR JIT - 20060428_1800_r8 GC - 20060501_AA) JCL - 20060511a ------------------------ Failures => explanations: =========== ibm142: ----------------------- - derbyall/derbyall.fail:lang/dcl.sql - jvm message diff (Access denied vs. expected access denied) known. - derbyall/derbyall.fail:lang/predicatePushdown.sql - different scores, different paths... Diffs look reasonable. Test harness cannot currently handle this kind of ok diffing. - derbyall/derbyall.fail:tools/ijConnName.sql - timing diff of 'ERROR 08001: No suitable driver'. ok. Test harness cannot currently handle this kind of ok diffing. - derbyall/derbyall.fail:unit/cacheService.unit - hang/timeout - .... ???? - derbyall/demo/demo.fail:demo/RunClassPathTester.java - (Access denied vs. expected access denied) known - derbyall/derbynetclientmats/derbynetmats.fail:derbynet/checkSecMgr.java (Access denied vs. expected access denied) known - 15 derbynetmats tests fail because of extra jvm line in output from jcc driver. ibm1.5. with default jit operation: --------------------------------------------- runtimestatistics : - derbyall/storeall/storemats.fail:store/access.sql - derbyall/encryptionAll/encryptionAll.fail:store/access.sql - derbyall/encryptionAll/encryptionAll.fail:store/access.sql - derbyall/encryptionAll/encryptionAll.fail:store/access.sql - derbyall/encryptionAll/encryptionAll.fail:store/access.sql - derbyall/encryptionAll/encryptionAll.fail:store/access.sql - derbyall/encryptionAll/encryptionAll.fail:store/access.sql - derbyall/encryptionAll/storemats.fail:store/access.sql - derbyall/derbyall.fail:lang/subqueryFlattening.sql - derbyall/derbyall.fail:lang/predicatePushdown.sql - derbyall/derbyall.fail:lang/ddlTableLockMode.sql - derbyall/derbyall.fail:lang/outerjoin.sql - derbyall/derbyall.fail:lang/staleplans.sql - derbyall/derbyall.fail:lang/wisconsin.java - derbyall/derbynetmats/derbynetmats.fail:lang/optimizerOverrides.sql - derbyall/derbynetmats/derbynetmats.fail:lang/wisconsin.java - derbyall/derbynetclientmats/derbynetmats.fail:lang/wisconsin.java identity column - derbyall/storeall/storeall.fail:store/bug3498.sql - derbyall/derbynetclientmats/derbynetmats.fail:tools/ieptests.sql - derbyall/derbyall.fail:tools/dblook_test.java other known: - derbyall/derbyall.fail:lang/procedure.java - testImplicitClose intermittently fails...related to increased garbage collection in jvm. - derbyall/derbyall.fail:jdbcapi/setTransactionIsolation.java - garbage collection problem. ibm1.5. with immediate jit activation: (-Xjit:count=0) ---------------------------------------------------- failures because of runtimestatistics long numbers: derbyall/derbyall.fail:lang/distinct.sql derbyall/derbyall.fail:lang/orderbyElimination.sql derbyall/derbyall.fail:lang/desc_index.sql derbyall/derbyall.fail:lang/aggregateOptimization.sql derbyall/derbyall.fail:lang/distinctElimination.sql derbyall/derbyall.fail:lang/predicatesIntoViews.sql derbyall/derbyall.fail:lang/distinctFiltering.sql derbyall/derbyall.fail:lang/specjPlans.sql derbyall/derbyall.fail:lang/subquery.sql derbyall/derbyall.fail:lang/dynamicLikeOptimization.sql derbyall/derbynetclientmats/derbynetmats.fail:lang/optimizerOverrides.sql plus those that also failed with normal jit operation because of identity column large numbers: derbyall/derbyall.fail:lang/scrollCursors1.sql derbyall/derbyall.fail:lang/holdCursorJava.java derbyall/derbyall.fail:jdbcapi/checkDataSource30.java derbyall/derbyall.fail:jdbcapi/checkDataSource.java derbyall/derbyall.fail:lang/modifyColumn.sql derbyall/derbyall.fail:lang/syscat.sql derbyall/derbyall.fail:jdbcapi/odbc_metadata.java derbyall/derbyall.fail:lang/autoincrement.sql derbyall/derbyall.fail:jdbcapi/metadata.java derbyall/derbyall.fail:tools/ieptests.sql derbyall/derbyall.fail:jdbcapi/characterStreams.java derbyall/derbynetmats/derbynetmats.fail:lang/scrollCursors1.sql derbyall/derbynetmats/derbynetmats.fail:lang/syscat.sql derbyall/derbynetmats/derbynetmats.fail:jdbcapi/odbc_metadata.java derbyall/derbynetmats/derbynetmats.fail:jdbcapi/metadata.java derbyall/derbynetmats/derbynetmats.fail:tools/ieptests.sql derbyall/demo/demo.fail:demo/checkToursDB.java derbyall/derbynetclientmats/derbynetmats.fail:lang/scrollCursors1.sql derbyall/derbynetclientmats/derbynetmats.fail:lang/holdCursorJava.java derbyall/derbyall.fail:tools/dblook_test.java derbyall/derbynetmats/derbynetmats.fail:derbynet/dblook_test_net.java derbyall/derbynetclientmats/derbynetmats.fail:derbynet/dblook_test_net.java derbyall/derbynetclientmats/derbynetmats.fail:jdbcapi/checkDataSource30.java derbyall/derbynetclientmats/derbynetmats.fail:lang/syscat.sql derbyall/derbynetclientmats/derbynetmats.fail:jdbcapi/odbc_metadata.java derbyall/derbynetclientmats/derbynetclientmats.fail:jdbcapi/checkDataSource.java derbyall/derbynetclientmats/derbynetmats.fail:jdbcapi/metadata.java plus those that failed with normal jit operation. Finally, note that it was not possible to successfully run the upgrade suite with this jit setting because the test harness currently cannot pass 2 jvmflags (see DERBY-1091), and we'd need to pass both derbyTesting.jar.path and -Xjit:count=0. ===============
