[quote]http://java.sun.com/docs/performance/
http://java.sun.com/j2se/1.4.2/1.4.2_whitepaper.html
Nothing for 1.4.1 or 1.5 (yet).
[/quote]
Those papers don’t give definitive answers about what optimizations ARE done in the client VM . For instance they don’t even mention that the SSE/SSE2 instructions are only used by the server VM. Thanks for looking though :).
[quote]Are you saying that the hotspot JVM is ‘smart’ enough to remove array bound checkings before 1.5 ?
[/quote]
Bounds check hoisting has been in the compiler since 1.4
JK
[quote]Bounds check hoisting has been in the compiler since 1.4
[/quote]
Surely bounds check hoisting is part of the JVM? Or have I misunderstood something… :
Wouldn’t it be a security hole to trust the bytecode that an index is in range?
He means the Just In Time Compiler… when HotSpot compiles to native code.
…and it’s only in the much-unused, horribly-slow-to-start-up server VM 
Cas
[quote]…and it’s only in the much-unused, horribly-slow-to-start-up server VM
Cas
[/quote]
The one with the incredibly sophisticated install procedure for adding to the public JRE.
Can you specify the server JVM with webstart (and have it downloaded if not present)?
The startup looks like being even slower relative to the client JVM in Tiger — the shared class stuff seems only to apply to the client VM.
I don’t believe you can explicity specify the server VM in Webstart yet. It’s not a great solution anyway - we still rather desperately need the hybrid 2-stage VM instead of separate client and server VMs.
Sharing classes is enabled with the server VM but not initialized by default. Run java -server -Xshare:dump and it’ll create the shared classes file for the server VM. Working well here.
Cas
Huh? Explain this? To my knowledge the only thing you need to do in the JRE to get the server VM is type -Xserver on the command line.
No install required.
For the Java JRE 1.5 ?
For the Java JRE 1.4 it’s different. Just you lucky Apple users have got the server VM by default. We poor Windows users don’t see any server VM bundled in the JRE 1.4. At dev time you can copy the JDK’s server VM dll folder to the JRE so that sending the following command works: java -server -version
Maybe this is what Mark meant?
Jeff is mistaken; you still need to copy the DLL. In beta1 at least.
The Apple server VM is not the same as Sun’s server VM. It merely changes memory tuning characteristics (at this point in time).
Cas
Exactly. A default install of java 1.5 beta gives this in response to java -server -version
Error: no server' JVM at C:\Program Files\Java\j2re1.5.0\bin\server\jvm.dll’.
Hmm. Thats the beta. Im not sure what that means if anything.
AFAIK there is no intent to stop destributing the server VM with the JRE but who knwos, maybe someone thought it was a brillaitn way to reduce JRE size.
I’ll poke around and see what I cna find out.
Umk are you guys telling me its been this way since 1.4?
Thats nutty. I need to look into that. Thanks.
[quote]Umk are you guys telling me its been this way since 1.4?
[/quote]
Yes.
You live in a nice world: no Windows PCs for years. Lucky you…
[quote]Umk are you guys telling me its been this way since 1.4?
[/quote]
Since the server VM was released (1.3 ?).
You could at least make the server VM an option in the JRE install so that you don’t have to download it unless you want to.
Cas
[quote]Umk are you guys telling me its been this way since 1.4?
Thats nutty. I need to look into that. Thanks.
[/quote]
Yep, there’s not server VM in Windows JRE for a long time now. However, Linux 1.5.0 beta JRE has it. Sweet.
You mean its just the 1.5 JDK installation which doesn’t copy the server vm to the JRE location? That 's just nutty.
Yes it has always been the case that the server VM is not included in the “JRE” but is included in the “JDK”, on Windows at least.
On Mac there currently is NO server VM at all, but the -server command line arg does change some parameters to the client VM so it behaves a bit more server like - though without any of the server VM optimizations.
Heh, what a mess! ;D
I’d always assumed that the reason why the server VM wasn’t in the JRE was because most people wouldn’t know it was there anyway - it’s an easy 2MB to cut. The minority who want the server VM are capable of getting the full JDK instead - classical client-side apps would prefer to avoid the startup cost so it’s application servers et al that really benefit, and they frequently come bundled with the preferred VM.
That was always my perception, anyway.