A DESCRIPTION OF THE REQUEST :
there's no client compiler for 64-bit linux. there should be.

JUSTIFICATION :
the server compiler can cost too much, especially for short-lived programs. even long-lived but interactive programs make a bad impression when they take a long time to start up. most users switching to 64-bit Linux from 32-bit Linux have complained that my software "is slower" on their new 64-bit machine. investigation shows that they almost all mean "starts slower". (funnily enough, this seems to make them more sensitive to any slowness while running, even if the application's own logging shows that it's no worse than when run on a 32-bit JVM.)

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
i'd like to have the client compiler ported to 64-bit architectures. (at least Linux. i've yet to hear from a single user of 64-bit Windows, Solaris, or Mac OS. it's getting increasingly common among Linux users, though, and i imagine that the other OSes can't be more than a couple of years behind the trend.)
ACTUAL -
there's no 64-bit client compiler.

CUSTOMER SUBMITTED WORKAROUND :
install the 32-bit JVM on the 64-bit host. this suggests a potential work-around for Sun, too: package the two JVMs together in one tree, and when the launcher does its usual JVM-choosing, let it choose the 32-bit JVM if you ask for -client.
Posted Date : 2006-08-14 09:36:21.0

N/A

Would also be good to get 64bit c1 on sparc so that 64bit sparc/intel could run tiered.
Posted Date : 2007-05-17 19:12:06.0

http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/dc7f315e41f7
Posted Date : 2008-08-27 09:47:33.0

5108146: Merge i486 and amd64 cpu directories
6459804: Want client (c1) compiler for x86_64 (amd64) for faster start-up
Reviewed-by: kvn

These are the changes from Steve Goldman to merge the 32 and 64 bit
assemblers together.  I did final merging and testing of these changes
and am technically a reviewer of these changes.

This webrev merges the code in assembler_x86_[32|64].* into
assembler_x86.*. The webrev shows it as assembler_x86.* as new files
and assembler_x86_[32|64].* as unchanged. When the commit actually
happens the 32|64 files will be deleted.  Not all files which could
have been merged have been but it should be possible to write a large
amount of assembly that will work for either 32 or 64 bit in the same
way this is done for sparc.

In addition to merging the assembler code the .cpp file was
restructured so that the instructions are in alphabetical order and in
3 sections, generic, 32bit only, 64bit only. As a result the diffs for
that file are incomprehensible.

This includes "ptr-izing" the assembly code throughout the x86
directory and changes to c1 to produce a 64bit c1. The spelling
changes that did the "ptr-izing" of the code may be controversial.
Operations that only can do a full register sized operation don't have
a size qualifier. So movl(Register, Register) or movq(Register,
Register) are now mov(Register, Register). push/pop/bswap also don't
have a qualifier either.

tested with ctw, runthese and nsk for {32, 64} bit X {client, server}
interpreter assembly was compared for between before and after to make
sure the generated code was the same.
Posted Date : 2008-08-27 18:08:15.0

There is no client VM in jre6u14. I think it has somthing to do with Bug 6746320?