JDK-6459804 : Want client (c1) compiler for x86_64 (amd64) for faster start-up
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 6
  • Priority: P5
  • Status: Closed
  • Resolution: Fixed
  • OS: linux
  • CPU: x86
  • Submitted: 2006-08-14
  • Updated: 2011-03-07
  • Resolved: 2011-03-07
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7 Other
6u14Fixed 7Fixed hs14Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
there's no client compiler for 64-bit linux. there should be.

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.)

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.)
there's no 64-bit client compiler.

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.

EVALUATION 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.

EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/dc7f315e41f7

EVALUATION Would also be good to get 64bit c1 on sparc so that 64bit sparc/intel could run tiered.