I was talking to a colleague about the -serve JVM option, or rather he was talking to me about it. I realized I really knew nothing about it, nor did he. I was wondering if anyone has experiences with it, what are the advantages vs. regular client?
He was under the impression that -serve compile to native, which I’m CERTAIN is false, but didn’t want to say anything before I had it confirmed.
Both client and server VMs compile bytecode to native code.
The server VM has more optimizations and compiles more aggressively. It tends to have a slower startup time because of this, and perhaps longer pauses caused by compiling the “hot spots”, but has generally better performance after it has decided to compile everything.
The client VM was designed for faster startup, followed by improved performance from compiling. The server doesn’t care so much about startup time - just performance. It may also use more memory.
[quote]Both client and server VMs compile bytecode to native code.
[/quote]
Well, yeah, heh. What I meant is he was under the impression that it compiles the byte code into native leaving the native code where it can be used later. Sounded like misinformation to me then, and still does after your response.
So basically it comes down to server slower start up faster running, client faster slower running. With memory issues thrown in.
Sounds well.
However if I try to run a Java application (with the official JRE) with the -server option, Java says it can’t find the server/jvm.dll (Win32) and indeed: there’s just a directory Jre\bin\client\ with jvm.dll inside.
The server JVM is “only” in the SDK’s Jre subdirectory.
So… normal JRE users cant use the server option…?
I’ve played some with the -server option (after actually finding the .dll for it… had to uninstall 1.4.2 and reinstall the sdk), and noticed three things:
A resonably tight loop I’ve got used to allocate more objects than the GC could be bothered to collect with the client jvm. This went away with the -server option.
The time required to read a bytebuffer from a random access file dropped to about 1/10th of the time it took with the client jvm.
It started a bit slower.
The server VM is included with the SDK, but is not in the runtime-only download.
It currently does not cache the compiled code.
There is a command line option to force everything to compile to native code. I think it is -Xcomp
Anyone doing significant floating point work should try out 1.4.2’s with the -server option. It uses SSE and I’ve seen large performance increases with it.
Oh well, the server JVM is only included in the SDK then.
That’s a pity. Then it’s useless to me because I don’t want to programm just for me. 
You can program for me too… I have the server VM :)… actually on the mac you only get the SDK, there is no separate JRE. So you can program for Mac users too
[quote]You can program for me too… I have the server VM :)… actually on the mac you only get the SDK, there is no separate JRE. So you can program for Mac users too
[/quote]
Didn’t know that. Mac is different. Think different.
Anyway, that’s good news.
Now if Microsoft could be convinced to include a recent Java SDK (or JRE) in every new Windoze and Service Packs. But before that happens, the hell will freeze… 
Luckily quite some Linux distributions (like Suse) include Java. Redhat too? Mandrake not, I read here in the forum. Those which do include Java: is it SDK oder JRE?
One day, I hope to go for a Mac.
Archimedes, you’ve missed a few lawsuits.
Microsoft thinks Java is EVIL. Sun sued them over your very point, won an injunction, and ultimately lost that particular point. Yes, Microsoft is in violation of screwing up the JVM they licensed, so guess what? They are NOT allowed to distribute any newer versions of Java.
Since they’re not allowed to write their own version of the JVM, I can pretty much assure you they would NEVER distribute Sun’s.
Oh, and have you heard about C# yet? The Java clone Microsoft wrote for .NET? That’s the other reason.
There are some pretty extreme benchmark figures floating around for how server VM performance beats client hands down in the NIO.* classes.
I recall one which looked only at memory-mapped I/O, and deduced that Server-MMIO was better than IO.* for medium sized files and above, whereas client-MMIO was always worse than IO.* (even on files up to many megabytes, IIRC).
…except that Solaris slaughtered everything elsem and Solaris-server-mmio was able to beat IO.* on nearly all file sizes.
If I were hazarding a guess, I’d say it’s something to do with the fact that much of NIO is claimed to have extreme startup costs (allocation of BB’s etc), and that full heavyweight NIO isn’t performed in client mode because this really is so extreme.
Witness the fact that things like BB aren’t recommended except for very large or very long-lived buffers, and yet many of us are using them almost exclusively, since they have so many functional benefits over IO.* code.
Shrug. Just a guess.
PS: IIRC server used to be more aggressive about re-compiling bytecode to native code multiple times, seeking better versions, on the assumption that it would typically be running for days, so the extra costs could be amortized and the benefits realized - things that would not manifest with less than hours of unbroken runtime.
I have a vague memory of server being advised only if you run the VM for “at least days” at a time, typically.
[quote]Since they’re not allowed to write their own version of the JVM, I can pretty much assure you they would NEVER distribute Sun’s.
[/quote]
Actually I think they are allowed to write their own… it just has to comply with Sun’s standards. They have choosen to not upgrade their VM and they can only distribute the version that they last complied with… which is way too old. But they still have the option to compete fairly with the rest of the world. They simply choose to abuse their monopoly instead.
True, very true, however, didn’t Sun cancel Microsoft’s Java license, or they chose not to renew, or something, preventing them from writing a 1.4 JRE or SDK?
Does Suse really come with a recent JRE? Is this a recent change in Sun’s licensing or Linux distros’s attitudes towards it? I know Mandrake 9.1 only comes with Kaffe and Slackware comes with nada (Debian, of course, will strike you down on the spot if you install a Sun JDK :)). Both Gentoo and FreeBSD refuse to install the JDK unless you go and download the file yourself and agree to the license, then they’ll take over and finish the job for you. I wonder what the deal is with Suse.
Sorry, lil off topic there…
[quote]True, very true, however, didn’t Sun cancel Microsoft’s Java license, or they chose not to renew, or something, preventing them from writing a 1.4 JRE or SDK?
[/quote]
IIRC, Microsoft has a license for only 1.1.4 and that there will be no problem if they wanted to license the most recent java as long as they conform to the standards. It’s just that MS never will for known reasons.
Head: “SANTA CLARA, Calif. and OAKLAND, Calif., 08/01/2003
SuSE Linux to Become a Java ™ Source Licensee and Distribute Sun’s Java, Sun to Distribute SuSE Linux Enterprise Server”
“SuSE commits to (…) to distribute Sun’s Java Virtual Machine™ (JVM) to further expand the deployment of the world’s most popular application environment.”
No mention however if it’s Java SDK or JRE what SUSE is going to ship. Anybody?
Then you arent listening, i fear.
The Sun VM is really 2 VMs in one. a “Client” VM and a “server” VM. -server tells the VM launcher to run the server VM.
BOTH CLIENT AND SERVER VMs CONTAIN Just-in-Time COMPILERS THAT COMPILE THE BYTECODE DOWN To NATIVE ASSEMBLY CODE.
The differences are in how they go about doing that. SWp did an excellent job of describing the differences on a high level so I won’t go into that again.
Is that all clear enough?
What your friend MIGHT be getting confused by is the -Xcompile flag on the Sun VM. This flag forces the VM to compile all the code at program start-up rather then on-the flay as-needed. It results in a longer pause til start of the prgoram but eliminates most of the “glitchiness” caused by the advanced optimizatio nanbalysis of the server VM during the early parts of a run.
[quote]Oh well, the server JVM is only included in the SDK then.
That’s a pity. Then it’s useless to me because I don’t want to programm just for me.
[/quote]
I dont want to make any specific promises here because I’m not a Sun lawyer, but you should look at the latest license for the SDK. Its become seignificantly more liberal on how and when it can be destributed then it used to.
[quote] Then you arent listening, i fear.
The Sun VM is really 2 VMs in one. a “Client” VM and a “server” VM. -server tells the VM launcher to run the server VM.
BOTH CLIENT AND SERVER VMs CONTAIN Just-in-Time COMPILERS THAT COMPILE THE BYTECODE DOWN To NATIVE ASSEMBLY CODE.
The differences are in how they go about doing that. SWp did an excellent job of describing the differences on a high level so I won’t go into that again.
Is that all clear enough?
[/quote]
No, I was listening and understand perfectly well. What I meant is HE was under the impression that it build natively permanently (think exe or dll), where you could then use it WITHOUT the jvm.
I was certain that it worked just the way you so passionately explained it, Jeff. However, due to his insistance that this is how it worked, I wanted to make sure.