java launcher option -d32/-d64

David Holmes david.holmes at
Wed Sep 21 22:01:47 UTC 2016

On 22/09/2016 12:22 AM, Coleen Phillimore wrote:
> On 9/21/16 10:17 AM, Jesper Wilhelmsson wrote:
>> Den 21/9/16 kl. 15:14, skrev Kumar Srinivasan:
>>> On 9/21/2016 1:17 AM, Jesper Wilhelmsson wrote:
>>>> Hi,
>>>> I think this is a good change. If a flag doesn't make sense anymore
>>>> we must
>>>> have the guts to remove it. We have way too many command line flags
>>>> to be
>>>> sentimental about them.
>>>> Updating all our tests that use the flag must of course be part of
>>>> the work
>>>> done to remove the flag. This is something that Kumar needs to take
>>>> into
>>>> account and staff when planning this work.
>>>> Updating scripts and other frameworks that are not part of our
>>>> shared source
>>>> base can obviously not be part of the work, but will have to be done
>>>> by the
>>>> maintainers of the scripts and frameworks. This is unfortunate but
>>>> we can't
>>>> let that stand in the way of a good change. Especially in a major
>>>> release I
>>>> think this is the kind of changes one have to allow.
>>>> One question though, should the flag be deprecated for one release
>>>> before
>>>> removing?
>>> That is the standard rule, ie. deprecate for one major release, launcher
>>> perhaps should perhaps accept the flags for jdk9 with a warning, and
>>> remove it in jdk10.
>> That would give people some time to clean up their scripts at least. I
>> think that is a good approach.
>> Make sure you run through all tests in jdk/test and hotspot/test
>> before pushing. (And there are likely other test lists that needs to
>> be verified as well.) I'd assume that many of our tests will be
>> surprised by the new warning.
> Please fix all the tests, test harnesses, etc *first*!   -d64 is
> everywhere.   Then make the change to the launcher.   Can you do this in
> the hotpot repository also so that it's tested?

I agree - a warning is likely to cause problems as well so all the uses 
of -d32/-d64 should be fixed before any changes are made to the launcher.

While we seem to see it everywhere in the testing I'm hoping it actually 
originates from a handful of places. There is actually very little use 
in hotspot (tonga setup), and not too much in jdk - see below - and in 
top-level test-lib.


> Thanks,
> Coleen


./lib/testlibrary/jdk/testlibrary/     * Get platform 
specific VM arguments (e.g. -d64 on 64bit Solaris)
./lib/testlibrary/jdk/testlibrary/            return 
new String[] { "-d64" };
   ${JAVA} -d64 -version > /dev/null 2<&1
${JAVA} -d64 -version
./java/awt/JAWT/        ${TESTJAVA}${FS}bin${FS}java -d64 
-version 2>&1 | grep '64-Bit' > $NULL
./java/awt/JAWT/        ${TESTJAVA}${FS}bin${FS}java -d64 
-version 2>&1 | grep '64-Bit' > $NULL
./java/util/Arrays/ java -d64 -Xms25g -Xmx25g Big 30
./java/util/Arrays/        // java -d64 -Xms13g -Xmx13g Big 30 2
./JTreport/html/notRun.html:>tools/launcher/ Verify 
-d32 and -d64 options are accepted(rejected) on all platforms
./ProblemList.txt:#  4. Make sure you try the -d64 option on Solaris
./tools/launcher/ * @summary Verify -d32 and -d64 
options are accepted(rejected) on all platforms
checkAcceptance(javaCmd, "-d32");
checkRejection(javaCmd, "-d64");
./tools/launcher/            checkOption(javaCmd, 
checkAcceptance(javaCmd, "-d64");
checkRejection(javaCmd, "-d32");
./tools/launcher/            checkOption(javaCmd, 
./tools/launcher/                 * java64 -d64, LLP_64 
is relevant, LLP_32 is ignored
./Makefile:#   Could include: -d64 -server -client OR any java option

More information about the jdk9-dev mailing list