Java Hotspot VM - an inferior web RIA runtime
RogerV
consumer JRE (quicker download time to where will start running
something, improved browser plug-in, better modularized runtime
library code, etc.), the Java JVM still remains an unsuitable runtime
for web applications.
The JVM still has too much overhead and memory foot print - it adds
27MB to my Safari browser's memory foot print when I load the first
page with a Java applet:
http://java.com/en/download/help/testvm.xml
Now Safari, and most existing browsers that support Java, will
typically run Java applets on the same JVM instance. So the overhead
of the JVM gets shared amongst all the applets. (I tested this by
opening the above link in multiple tabbed pages and the memory spiked
but went back down to the level it was at after loading the first
applet instance.)
Yet one of the architecture benefits of Google Chrome will be that it
will run a tabbed page in its own process instance - for isolation and
thus stability. This implies that the presence of a Java applet on a
page would cause a new JVM instance to be spawned. Hmm - 20 to 30 MB
overhead for every page an applet appears on?
We can likely expect that Firefox, Opera, and even IE will copy-cat
the process isolation feature from Google Chrome because it makes a
lot of sense, bestowing true benefit to users.
So assuming a trend toward process isolation of web pages, building
RIA apps in GWT instead of JavaFX looks to be a more scalable
approach. The Google Chrome JavaScript V8 runtime is going to be much
more efficient when running multiple GWT apps in each its own tab
session.
For all kinds of reasons, really, Google had no choice than to go down
the path of improving JavaScript vs expect they'd ever be able to
build out the future of the web on top of the Java JVM.
To expect that the JVM is a suitable runtime for web RIA is, alas, an
idealistic fatalism. And when it comes to web RIA I don't see how the
vaunted Java Hotspot VM can even be regarded as a crown jewel. It is
fine for server apps and traditional desktop apps (NetBeans), but
compared to V8, TraceMonkey, Silverlight CLR, and Flash Player
runtimes, it doesn't compete. The JVM is too big and complex relative
to those other runtimes - it doesn't have a suitable architecture for
running web RIA.
When starting down the path of the Consumer JRE and JavaFX, Sun should
have also designed a new JVM that is suitable for the web. And they
should have earmarked a subset of JavaSE that is specifically for
sandboxed web apps. That would then constitute what would first load.
A full JavaSE might then incrementally install at some point if the
user were to run, say, Java web start app.
These considerations were all very basic and rather apparent. I don't
understand why Sun missed the ball by such a wide margin.
Joshua Marinacci
account). I'd like to correct a few things you got wrong here:
> Now Safari, and most existing browsers that support Java, will
> typically run Java applets on the same JVM instance. So the overhead
> of the JVM gets shared amongst all the applets. (I tested this by
> opening the above link in multiple tabbed pages and the memory spiked
> but went back down to the level it was at after loading the first
> applet instance.)
This is true. One JVM is shared by all applets.
> Yet one of the architecture benefits of Google Chrome will be that it
> will run a tabbed page in its own process instance - for isolation and
> thus stability. This implies that the presence of a Java applet on a
> page would cause a new JVM instance to be spawned. Hmm - 20 to 30 MB
> overhead for every page an applet appears on?
This is incorrect . There will still be a single JVM instance shared
by all applets, regardless of the tab or page it is one (with a few
specific exceptions). This is a core feature of the new applet plugin
in JavaSE 6 update 10.
> We can likely expect that Firefox, Opera, and even IE will copy-cat
> the process isolation feature from Google Chrome because it makes a
> lot of sense, bestowing true benefit to users.
Which will be great, especially if they encourage adoption of of
JavaSE 6 update 10, as Chrome requires.
> So assuming a trend toward process isolation of web pages, building
> RIA apps in GWT instead of JavaFX looks to be a more scalable
> approach. The Google Chrome JavaScript V8 runtime is going to be much
> more efficient when running multiple GWT apps in each its own tab
> session.
Since one VM will be used (with appropriate protection between
applets), the cost of the VM will be amortized across the tabs, thus
making Java based frameworks (like JavaFX) more efficient.
> To expect that the JVM is a suitable runtime for web RIA is, alas, an
> idealistic fatalism. And when it comes to web RIA I don't see how the
> vaunted Java Hotspot VM can even be regarded as a crown jewel. It is
> fine for server apps and traditional desktop apps (NetBeans), but
> compared to V8, TraceMonkey, Silverlight CLR, and Flash Player
> runtimes, it doesn't compete. The JVM is too big and complex relative
> to those other runtimes - it doesn't have a suitable architecture for
> running web RIA.
When are you are saying 'the JVM' what you really mean is the JRE,
Java Runtime Environment. It is the JVM (the Java virtual machine)
plus all of the runtime libraries that make up the Java platform. The
JVM is actually the smaller portion.
Yes, the JRE is bigger than What MS, Adobe, and the browsers provide.
But it also does a lot more. There are plusses and minuses. We are
addressing the minuses, as I'll show below. In the plus category you
can do far more in a JVM based app than you can in a Flash or
Silverlight app, thanks to the rich API provided by the JRE and the
huge ecosystem of Java libraries out there.
> When starting down the path of the Consumer JRE and JavaFX, Sun should
> have also designed a new JVM that is suitable for the web. And they
> should have earmarked a subset of JavaSE that is specifically for
> sandboxed web apps. That would then constitute what would first load.
> A full JavaSE might then incrementally install at some point if the
> user were to run, say, Java web start app.
>
> These considerations were all very basic and rather apparent. I don't
> understand why Sun missed the ball by such a wide margin.
We haven't missed the ball. These are all good ideas, which is why we
are *already doing them* !. :)
Let me tell you a bit more about JavaSE 6 update 10, and some of the
future improvements in Java 7.
Part of update 10 is a kernel installer. It will install just the bare
minimum subset of Java required to run your typical Swing app. This is
about 4MB, compared to the 10+ for the full install. This bare
minimum will run a slower but smaller JVM and download just the parts
of the runtime needed for your app. Then, in the background, it will
continue to install the rest of Java, just as you suggest. Eventually
you will have the exact same bits on disk as if you had done the
traditional installer. (assuming it wasn't pre-installed when you
bought your computer, which is becoming more common).
So you can see, your idea is something we've been thinking about for a
while and implemented for JavaSE 6 update 10. Good idea!
There is a limit to how much optimization we can do with creative
downloading, however. The JRE is a big and complex runtime with a lot
of internal cross dependencies (there's far more to the JRE than just
the public APIs). In Java 7 we are adding modules support and are
beginning the process of modularizing the JRE. We are cutting the
cross dependencies, making the JRE modular and subset-able.
This is very exciting stuff that will ensure the JRE has a long and
prosperous future.
RogerV
requiring, I didn't see anything new going on in the installation
process. It looked to behave much as prior Java JRE installs.
When is the optimized web install process going to show up? Or what
does it take to get that to happen if it is already there?
I'm basically looking for an install process that goes much like the
typical Adobe Flash Player install.
Also, what about that applet tear-out feature we hear about? I tried
to tear away the applet that appears on this page and nothing happens:
http://java.com/en/download/help/testvm.xml
Too, here's a wee bit of a QA heads-up:
I was running an Oracle-written java applet in Google Chrome, and at
some point the app froze up. Now that's not so unusual for Oracle
software. However, after I used Google Chrome task manager to kill the
page, and then got out of Google Chrome altogether, the Java process
instances was still around - it got orphaned. I had to use the Windows
taskmanger to kill it explicitly.
Is there something the Java browser plug-in can do to know when to
take down the Java JVM process it creates under such adverse
circumstances?
Also, if Google Chrome is a parent process and fully exits (or is
killed), should the Java process go down by sake of being a child
process? What exactly is the relationship there?
I understand there's intent to support tearing applets away and let
them start running independently of the browser. That would imply
wanting such an applet to remain running even if the host browser
process goes away. Okay, but perhaps when tearing applets out to run
independently, their own private JVM instance might be spawned.
All I'm getting at is that in the usual case the Java process should
go away if the host browser process goes away for any reason. It
shouldn't be left as an orphaned process. Seems the way to do that is
make it a dependent child process that is killed automatically by the
system in the event the parent process goes away.
Well, coordinating these multi-process scenarios and getting them to
behave to the user like a simplistic monolithic app in a single
process, is always an interesting challenge. The trick is to
orchestrate things in such a way that the host operating system will
do the necessary purge or resources (like processes) when things go
badly. Hoping to handle some aspects of adversity in the app software
layer can run into robustness issues.
hayden.p...@gmail.com
https://jdk6.dev.java.net/plugin2/#EXPERIMENTAL_FUNCTIONALITY
If I understand correctly, applets by default are not draggable.
Michael Neale
1) I doubt (from what little I have seen) that silverlight is much
better, it may be "good enough" though, but its not as light at ajax
or flash.
2) I think lightness of process could also be useful for server apps
as well (as in many hosting environments people do actually want to
run multiple processes to get maximum isolation).
Joshua Marinacci
On Sep 6, 2008, at 1:46 PM, RogerV wrote:
>
> When I installed the Java 6 1.6.0_10-rcb28 that Google Chrome is
> requiring, I didn't see anything new going on in the installation
> process. It looked to behave much as prior Java JRE installs.
>
> When is the optimized web install process going to show up? Or what
> does it take to get that to happen if it is already there?
You were using the standard installer. For the new optimized one you
should use the deployment toolkit which will auto-launch the kernel
installer if the javascript detects that Java isn't present. There is
some documentation on this already but new docs will come with the
final release of update 10.
> Also, what about that applet tear-out feature we hear about? I tried
> to tear away the applet that appears on this page and nothing happens:
>
> http://java.com/en/download/help/testvm.xml
Draggability must be enabled explicitly by the applet developer.
http://java.sun.com/developer/technicalArticles/javase/6u10_applets/
> Too, here's a wee bit of a QA heads-up:
>
> I was running an Oracle-written java applet in Google Chrome, and at
> some point the app froze up. Now that's not so unusual for Oracle
> software. However, after I used Google Chrome task manager to kill the
> page, and then got out of Google Chrome altogether, the Java process
> instances was still around - it got orphaned. I had to use the Windows
> taskmanger to kill it explicitly.
>
> Is there something the Java browser plug-in can do to know when to
> take down the Java JVM process it creates under such adverse
> circumstances?
>
> Also, if Google Chrome is a parent process and fully exits (or is
> killed), should the Java process go down by sake of being a child
> process? What exactly is the relationship there?
The point of running out of process is to protect the browser in case
the Java applet crashes or hangs, which is exactly what happened.
Chrome didn't lock up when the applet froze. Even if the app hadn't
frozen, you could have killed the Java process with the task manager
and the browser would still be fine.
> I understand there's intent to support tearing applets away and let
> them start running independently of the browser. That would imply
> wanting such an applet to remain running even if the host browser
> process goes away. Okay, but perhaps when tearing applets out to run
> independently, their own private JVM instance might be spawned.
>
> All I'm getting at is that in the usual case the Java process should
> go away if the host browser process goes away for any reason. It
> shouldn't be left as an orphaned process. Seems the way to do that is
> make it a dependent child process that is killed automatically by the
> system in the event the parent process goes away.
This is the usual case. The vm process will shut itself down if the
browser closes, unless there are applets which have been dragged out.
In general the VM will monitor itself and do a good job of keeping
itself resident for speed, and closing itself down when not needed.
The reason the VM didn't quit when the browser did is because your
applet froze, which is exactly what would have happened if the applet
had been a standalone desktop app. This is exactly as it should be.
> Well, coordinating these multi-process scenarios and getting them to
> behave to the user like a simplistic monolithic app in a single
> process, is always an interesting challenge. The trick is to
> orchestrate things in such a way that the host operating system will
> do the necessary purge or resources (like processes) when things go
> badly. Hoping to handle some aspects of adversity in the app software
> layer can run into robustness issues.
Yep. The new plugin actually has a small headless instance of Java
which does run inside the browser. This instance manages all of the
other ones (since there are cases when there *should* be more than one
worker instance). It will shut down and start up the worker instances
as necessary in the most efficient manner. And of course its
heuristics will improve over time.
- Josh
>
> >
sherod
As a purely unscientific asides loading this page, using a Javascript
RIA based technology, adds 30MB to my Safari footprint
http://www.extjs.com/deploy/dev/examples/desktop/desktop.html
And loading this flex based demo site adds a 110MB
http://flex.org/showcase/
It's interesting, a few years ago, both Flex and JS based RIA
approaches would have been totally unsuccessful on the basis of
download size alone with the minimum Flex app is about 500Kb (2x the
size of the flash runtime if I recall correctly!) and EXT JS weights
around the same size in Javascript source code - all before you write
a line of code or add an image yourself.
Some 13 years after applets turn up, with GB of ram and Ghz of
processing power, we're still saying Java is too big, too slow for the
desktop - My laptop has more processing power and available RAM than
half the LPAR images we deploy our web apps to on production, and
certainly more than the servers of 5 or 10 years ago.
For me, in my reading of a lot of the Update 10 stuff, Sun is moving
to rectify or improve a great many things. The next 12 months will
see if they have succeeded.
I'm hoping for the best.
RogerV
SP3 that I had installed Google Chrome on.
When I added the Adobe Flash Player for the first time, it was ready
to go in just a few seconds.
When I installed the Java 6 JRE that Chrome required, it was a lengthy
and involved undertaking. Of course I was motivated to do it anyway as
I have specific Java software that I want to run.
We've been hearing about this great new install process for Java in
the browser and I was fully expecting to experience that, given this
is touted as a RC (release candidate). It's too bad that it's still a
developer-only reality. The clock keeps ticking and Sun still isn't
there with a Consumer JRE.
Also, the JVM is too much overhead when every Java app that is kicked
off requires its own instantiation - even on today's typical hardware.
Josh says they'll share a JVM instance for applets, but that will have
stability implications on a browser like Chrome. What happens when a
page with an applet on it goes bad and is killed off by the user via
the Chrome task manager, and the user still has other applets running
in other good tab sessions? Will the JVM purge the applet hosted on
the bad page properly - in the event its hosting page is killed
abruptly? Could the JVM get destabilized by such an occurrence? What
would arguably be more robust is to spawn a JVM instance per every
tabbed web page that host an applet. Yet that would incur too much
resource overhead.
Sun never went all the way to delivering anything from its research on
single JVM running multiple Java applications robustly. Or else where
multiple JVM instances share a lot of common state to keep overhead
lower. So we're left with running all Java applet web apps in a common
JVM and hoping everything stays well behaved.
That's not the approach Google is taking with JavaScript-based apps
running under Chrome. They will be process-isolated and bad guys will
be nukable.
Casper Bang
> which does run inside the browser. This instance manages all of the
> other ones (since there are cases when there *should* be more than one
> worker instance). It will shut down and start up the worker instances
> as necessary in the most efficient manner. And of course its
> heuristics will improve over time.
within an application, without having to rely on a native wrapper or
have the user start the app up manually?
/Casper
Joshua Marinacci
technically possible. The most likely place for it would be an
additional service available to Java Webstart apps, similar to the
single launch service. Esp. now that both applets and webstart apps
share the same infrastructure.
- Josh
Michael Neale
appears to be heavier behind the scenes.
So if the new installer aids with this, it could be on to something.