Many tests (roughly 89) in the master 1.4.2_11 regression workspace at:
  /net/nightsvr.sfbay/export4/integration/1.4.2_11/j2se
use the following syntax to decide 64 bit execution:

    if [ -f ${FILE_LOCATION}${FS}JDK64BIT -a ${OS} = "SunOS" -a `uname -p` = 'sparc' ]
    then
        BIT_FLAG="-d64"
    fi

These may be searched for using:
  find /net/nightsvr.sfbay/export4/integration/1.4.2_11/j2se/test | grep -v SCCS | xargs grep '`uname -p` =' | grep JDK64BIT
(The reason for using this exact search criteria is explained later)

For example line 32 of:
/net/nightsvr.sfbay/export4/integration/1.4.2_11/j2se/test/CTE_REGTEST/Generic/5002890/Test5002890.sh

The above logic implies that if we have a JDK64BIT sentinel file in our home directory and are
using SunOS on a sparc platform, the -d64 bit option will be used in this test.

So for amd64 platforms, when I run these particular tests against the 64 bit JDK,
I will _never_ get a 64 bit test invocation, because of the "sparc" check.
This is even if I have specified -d64 as an option to my typical $JTREG_TOOL call

    export MYOPTION="-d64"
    $JTREG_TOOL -jdk:$JAVA_HOME $MYOPTION $CPA_OPTION $TESTBASE/test

So there is some inconsistency between the sparc and amd64 bit platforms
for running these tests, along with the misleading test configuration assumption.

However, there is a more serious inconsistency between this group of tests and another.
The other group of tests (roughly 370) use the following exact syntax:

    if [ -f ${FILE_LOCATION}${FS}JDK64BIT -a ${OS} = "SunOS" -a `uname -p`='sparc' ]
    then
        BIT_FLAG="-d64"
    fi

These may be searched for using:
  find /net/nightsvr.sfbay/export4/integration/1.4.2_11/j2se/test | grep -v SCCS | xargs grep '`uname -p`=' | grep JDK64BIT

For example line 40 of
/net/nightsvr.sfbay/export4/integration/1.4.2_11/j2se/test/CTE_REGTEST/Generic/5032314/Test5032314.sh

Note in particular the use of _no_ spaces in the token `uname -p`='sparc'
This is a syntax error.

eg. on AMD64:
balboa 5.10 # uname -p
i386

The token "i386=sparc" always resolves to true in Bourne/Korn shell when used with [ ... ] construct.
So even though I am not on Sparc architecture the buggy platform statement actually passes and applies the 64-bit Flag.

These 370 odd tests are completely inconsistent with the first group.
Paradoxically they may probably provide the desired test behaviour.
I actually get a 64-bit VM invocation where the code semantics did
not intend so, but the buggy syntax actually provided it.

The -d64 bit tests did not actually raise many issues - I had 6 failures, mainly
due to native tests where there was no appropriately named native
64-bit library to link with.

eg.
/net/nightsvr.sfbay/export4/integration/1.4.2_11/j2se/test/CTE_REGTEST/Generic/4178050/Test4178050.sh

So a number of aspects need to cleared up:

1. Should AMD64 execution apply 64-bit option where user has configured for it in general?
2. 370 odd tests need syntax correction for consistency with correctly coded tests
3. 6 odd tests need more careful syntax to handle native library or other aspects that may complicate decision.
4. All associated code should have appropriate comments to ease debug of these anomalies.
5. There may be other issues in the regression codebase related to the improper bourne syntax for other decision logic. These will be bugged accordingly.
Note: With regard to point 5 above, no other syntax problems apart from
the sparc tests were observed in checks