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.

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.

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.

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

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

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?

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.

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

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.

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.

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.

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?

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.

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?

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.

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.

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.

Got a question about Java and game programming? Just new to the Java Game Development Community? Try my FAQ. Its likely you'll learn something!

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

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.

Got a question about Java and game programming? Just new to the Java Game Development Community? Try my FAQ. Its likely you'll learn something!

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org