VM to OS

[Buch]

So, looking at Java platform (not just language), it is hard not to notice
how VM is actually terrible waste of CPU cycles.
Yes, yes, benchamrks, does not shows as large overhead for most of time,
etc, etc ...
But, theoretically speaking it is waste of CPU cycles.
As I understand, there is division in Sun's software division that makes VM,
and other is "porting" that VM to specific OS.
So, there are lot of knowledgeable people knowing inside and out every OS
for which they made VM port.
Integrating Java into OS, instead of having VM, could be hard for
proprietary OS-es, but they have their own Solaris, and Linux.
Java apps would therefore perform better on such Java enabled OS-es, and
there would be no jre distributions, only updates.
That would lead other OS companies to integrate Java also, or at least allow
Sun to do it. (Perhaps not MS, but then all that Java users would not care
for MS desktops, so I think MS would also).


--
Replace zeroes with "o" to reply

[Shankar Unni]

Post by Buch
Integrating Java into OS, instead of having VM, could be hard for
proprietary OS-es, but they have their own Solaris, and Linux.
Java apps would therefore perform better on such Java enabled OS-es

:-) ** 2!

That was exactly the theory that Sun must have postulated when it pushed
Java. It was hardly for "altrustic" reasons - what reason would Sun have
to push a platform that made it easier to run on AIX?

It was meant, of course, as a wedge against Windows, but one that would
give Sun an early leg up against its competition, because it would be
able to integrate it much better into Solaris.

Well, that theory has fallen by the wayside. Even among CPUs with
equivalent speeds (MHz), Java runs much better on Intel platforms than
on Sparc (or HP-PA, or Power), and even among the Intel platforms, it
runs best on Windows (oh, the irony!).

The reasons are legion. Some of them are:

1. CPU technology: One of the biggest is that since Java is not a
compiled language, there isn't much opportunity to optimize the code to
maximize the pipeline usage on traditional RISC CPUs (oxymoronic term!)
like Sparc (which rely on optimizers to issue instructions in the right
sequence to saturate the CPU pipelines).

On the other hand, with Intel CPUs, they had no illusions about
customers (or rather, the software vendors from whom they bought their
programs) using fancy optimizers to help them, so they designed their
CPUs to automatically rearrange instructions within the issue logic to
saturate their pipelines. The latest Intel CPUs can keep an astonishing
number of instructions "in flight" at a time (I believe the Prescott
series can issue upto 42 instructions out of order!).

So one side-effect has been that however poorly the Java VM issues
instructions, the Intel CPU executes it well. So it runs rings around
Sparc CPUs of equivalent MHz. Sun has made great strides in its recent
CPUs, but it's already miles behind Intel on this front. Intel has a
hundred times as many CPU designers, and spends probably a hundred times
as much, and the lead is just increasing.

2. The "OS layer" isn't all that deep. The Java runtime is generally a
fairly thin layer over the native OS functionality - it only normalizes
the behavior across the various platforms. So "embedding it" into the OS
provides very little benefit.


Basically, there isn't much Sun can do at this stage to make Java run
better on its platforms than a commodity Intel-based platform.

[Buch]

Post by Shankar Unni
:-) ** 2!

Was that "!" exclamation, or factoriel operator? :)))

Post by Shankar Unni
So one side-effect has been that however poorly the Java VM issues
instructions, the Intel CPU executes it well. So it runs rings around
Sparc CPUs of equivalent MHz. Sun has made great strides in its recent

So, Java embedded into Linux performing on Intel CPU would be nice, however
same Linux on non-Intel architecture CPU would not be worth of trouble?

[Shankar Unni]

Post by Buch
Was that "!" exclamation, or factoriel operator? :)))

:-)

Post by Buch
So, Java embedded into Linux performing on Intel CPU would be nice, however
same Linux on non-Intel architecture CPU would not be worth of trouble?

Hard to say. It's just that at least on the face of it, there doesn't
promise to be much of a potential gain in embedding a Java runtime like
this, so it's difficult to justify the effort required in doing such an
integration just to "try it out".

There are some research projects in virtual machines to speed up
execution of programs. Also, static compilation is always an option
(either directly from source, like gcj, or from the byte code itself,
though you lose a lot of high-level semantic information that way).

Currently, the ever-faster Intel CPUs are bailing out the Java VM guys,
so the focus of the Java community is on APIs. In general, across much
of the business user base, raw processing speed is not as much of an
issue as useful APIs and interoperability with other systems.

With the upcoming detente between Sun and Microsoft, expect to see a lot
more activity on bridging Java and DotNet, which is where the real bang
for the buck lies..

It'll be interesting to see how (or if) Sun forms a new business model
around this!