Skip to main content

Java Kernel. How it is ? When it will be part of JSR ?

26 replies [Last post]
ivanooi
Offline
Joined: 2005-06-27

Hi,

Is there any news about Java Kernel lately ? I cant find any things about it in JSR. Any ideas ?

Thanks and hope it will be part of Java 7

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
bcchun
Offline
Joined: 2003-06-11

btw, you are right, from looking at the source, it looks like its mapped ;-).

deklotz
Offline
Joined: 2006-03-03

I agree, and thanks for posting the information. I was not able to attend.

I am glad they are doing the option for keeping the files in disk cache. Hopefully that will have very real world benefits.

On a slight tangent I offer the following that I found to be a good read:

http://www.humanfactors.com/downloads/apr01.asp

-Dennis

augusto
Offline
Joined: 2003-06-11

Cold startup times are a planned improvement coming up in Java 6 Update 2. The VM will be kept in the system disk cache, not on RAM, by something called QuickStart.

http://sellmic.com/blog/2007/05/16/easy-deployment-is-finally-here-sessi...

* BTW there is no JSR related to this VM, and according to all the info @ JavaOne this is coming for Java 6, not 7.

bcchun
Offline
Joined: 2003-06-11

thank you for posting this! Especially for those of us who couldn't make it, your blog was an excellent read. I'm still a little disappointed that they are not being more aggressive in terms of slimness. I think the goal should be to have a similar experience to Flash in terms of load time (I know its not flash ;-).

bcchun
Offline
Joined: 2003-06-11

no they are not ;-). the shared data archive is an intermediary optimized structure, but that still isn't enough IMO. Why wouldn't we compile the whole thing down for a target platform? You can still leave user code in jar's, but the runtime should be highly optimized. Imagine if the Flash OCX control took as long as the warm boot for the JVM. It would be delegated to where applets are now b/c it is unacceptable in terms of user experience. Disk caching in the background may alleviate some of this, but for goodness sakes, without the distribution, startup time, and load times for applets/web start being reduced to imperceptible, we will have acceptance problems. The scheduled updater is native and runs as a windows service that starts up automatically.

In terms of parts that are optimized, classes.jsa itself is almost 13 megs.

sjasja
Offline
Joined: 2004-08-15

> no they are not ;-).

Is this in reference to "Aren't most of the things that comprise the JVM already memory mapped?" I'm looking at hotspot/src/share/vm/memory/filemap.cpp; does that look like it's mapping classes.jsa? I think it's possible to mmap() other things besides .exe files.

As to why not pre-compile: dynamic compilation can do things like inline methods. Which is pretty useful in OO programming, which tends to have lots of little methods. Static compilation doesn't know what methods are overridden, so it can't do as much optimization as dynamic compilation can.

Some small, short-running, performance critical programs (if there is such a thing) may be faster when static compilation is used; depends on the balance of runtime compilation time vs benefits of dynamic compilation. I sure hope all this applet-centric optimization isn't done at the expense of everything else.

bcchun
Offline
Joined: 2003-06-11

I'm wasn't referring to just exe's. I'm not even referring the exact technical details, just to not rewrite the wheel in terms of the load times. I'm also not even referring to an applet-centric perspective, although, I personally think for the end user, that option is more important than you imply it is. I was simply giving an example of what I have/am using to optimize the client experience for my swing apps.

I agree with the advantages of hotspot, no argument there. I'm simply talking about environment, of which there are many, where the user expects the "widget" to show up instantaneously, or darn near fast as possible. That is where the goal should be IMO. And yes, I think it needs to be a flash like experience this way. Not just for the browser, but for desktop apps, and especially for applications where the startup/footprint/distribution problems can be solved and we can start to think about inverting the perspective of browser only applications, meaning, using the desktop rich client to among other things, host a browser.

There are I think many other issues to solve. We all know we can basically get Java to do most anything, but its the sweet spots of productivity and efficiency, of platforms like Flash/Flex that needs to be considered also to have Java be more of a player on the desktop than applications written to either the Adobe or Microsoft SDK's.

I'm really just trying to stress how important the end user experience is, and the experience of the developer in deploying to those end users. Once that is tightened up, the sheer inerntia of activity within the community will be huge.

bcchun
Offline
Joined: 2003-06-11

we've recently been using a certified JVM from excelsior and their JET product which uses ahead of time compilation. The interesting thing is, the whole thing including the JVM can be compiled down to a native executable. One of the things that frustrates me personally, is the question of why the JRE can't be completely compiled down natively on the target system (I know, specs, etc, purity), at the same time, we have different native executable parts for each platform, can't we get the whole thing streamlined into native code so we can memory map the darn thing to get rid of the size/start up issues? The Flash ocx's together make up about 4.5MB, but they load really really fast in the browser.

sjasja
Offline
Joined: 2004-08-15

> can't we get the whole thing streamlined into native code so we can
> memory map the darn thing to get rid of the size/start up issues?

Aren't most of the things that comprise the JVM already memory mapped? Including jar files?

On my PC the JVM starts up in about 0.1 seconds. (Test your computer: public void main(String s[]) { System.out.println(System.currentTimeMillis()); }. Run that 11 times in a shell script, subtract last printed time from first printed time. If the total is 1 second, one startup and shutdown = 0.1 seconds.)

The first "cold" JVM startup takes longer; several seconds. I suspect this is mostly the OS paging out stuff. The same several-second-wait happens when I start a GNU program written in C or C++ the first time: the OS swaps in Cygwin's .dll files that contain the C/C++ runtime. Those programs are 100% precompiled machine code. Precompiled machine code is just as slow to page in (or the previous stuff to page out) as rt.jar.

Some measurements would be nice, before someone spends a lot of time doing an "optimization" that has little or no effect... And has the speed downsides that precompilation has.

deklotz
Offline
Joined: 2006-03-03

Is this what you are asking for? Well probably not since this is dealing with previous versions of the jvm, but I think it is a good read. I provided detailed information on start times for different versions of the JVM. (about 1/3 the way down the thread)

I created this thread and helped with the bug creation about two years ago, but I think it still needs to be addressed. The work specified in this thread, sounds like it will help in the area of initial download but not with cold start times. Which is exactly what the following forum and bug ask to be addressed.

Take a look. :)

http://forum.java.sun.com/thread.jspa?messageID=3962327
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6346341

-Dennis

ivanooi
Offline
Joined: 2005-06-27

Hi Enicholas,

I think Sun should promote more on Java Kernel and I believe this will solved using Java as thin client solution. of cause, start up time must solved 1st...

There's too many web site saying Java are not the best solution if compare to Flash or AJAX... I think Sun should make Java Kernel part of Java 7 AND promote it more :-)

I really really happy to hear that Java Kernel really work! in that case, "make it so, No.1"

Thanks again Enicholas. :-)

prime21
Offline
Joined: 2005-06-15

Ethan,

That's outstanding news that you were able to get the JRE down to 2.5MB. Smaller is better, but 2.5MB (wow!) has already exceeded my hopes for a smaller JRE.

I spent about 3 hours paring down the JRE myself on my own system and got it to 5.5MB (re-compressing rt.jar with pack200, etc). This is very exciting news to me. I hope Sun ships the JRE in this configuration.

If not, though, what's to stop a user like me from paring down the JRE myself and distributing a private JRE? It's GPL'd code after all, I can do what I want. I may not be able to call it "Java" anymore, but for the desktop apps I want to distribute, I don't care. I just want it to work and have a small installer foot print. Sun has to realize that if they don't do this officially (what you're working on), developers will do it anyway (and probably in a broken and incompatible way).

Many people have Java installed (70%+), but almost no one has JSE 6. The desktop improvements in JSE 6 are so huge that I can't even stand the thought of my app running on an older JRE. Thus, I must bundle the JSE 6 JRE. I hope Sun realizes that this is a common issue and you and your team are providing the solution.

If Java were small (and modular), it really would be everywhere on the desktop.

Thanks again for your great work,
-Bryan

enicholas
Offline
Joined: 2006-02-27

The 2.5MB is the core installation -- this does not include AWT, Swing, or anything else not strictly essential. You can go even smaller than that if you start to leave out components like Web Start and the Java Plug-In, but Sun's official distribution obviously has to support those. The package gets up in the 5MB range if you're using Swing.

And you hit the nail on the head -- the fact that people want a stripped-down JRE and, being open source, we can't stop them from doing that is one of the driving forces behind this. By providing our own implementation, we hopefully reduce the impetus for people to do this themselves, and then we have folks distributing a 100% compatible version of Java complete with Plug-In and Web Start support, rather than a half-formed monstrosity which cannot be called Java.

We can't get as small as a truly stripped-down JRE, because we have compatibility and functionality requirements to adhere to that 3rd-party developers probably don't care about. But we can get [i]close[/i] to the absolute minimum, and I'm hoping that's good enough to help.

ivanooi
Offline
Joined: 2005-06-27

Ethan, I really really hope to see Java Kernel come with Java 7.... 2.5mb download size really really help us a lot! Now I'm in the between of Flex or continue with Java.... because our customers asking for thin client.... :-(

Thanks

ivanooi
Offline
Joined: 2005-06-27

hmm.... just curious... what make Java launch time so different than Flash ? since it is not Java bytes files....

enicholas
Offline
Joined: 2006-02-27

> hmm.... just curious... what make Java launch time so
> different than Flash ? since it is not Java bytes
> files....

Java is far more capable and complex than Flash is, and unfortunately one of the prices you pay for that power is a bigger footprint. I have it on good authority that the vast majority of the time it takes to launch Java on a typical system is spent on disk I/O -- the VM itself starts up almost instantly (under 0.1 sec or so) if everything is already in memory.

From what I hear, most of the effort going into Java 7 startup time is being spent on the disk I/O issue. I'm not personally involved with startup performance, though, so don't take this as gospel.

ivanooi
Offline
Joined: 2005-06-27

I see..... Thanks!

nicolaiwadstrom
Offline
Joined: 2006-05-05

My 10 cents on the Java Kernel;

Great idea, done right will hold great promise for the Java platform;

When designing the Java Kernel; please look at the Apache Maven 2 model, it allows you to:

- Put a Project Model Meta-data in the JAR file, with dependency references to other modules (including version), works with chained dependencies as well (A requires B that requires C and so on).
- Local cache, and remote retrieval from repositories using HTTP.
- Established model, most Open Source and commercial projects use code that is already available in the public Maven repositories.
- There was an apache project that tried to solve the same problem (but only for user libraries) using Maven repositories; Apache Avalon Framework (now Metro; www.dpml.net, see http://www.dpml.net/util/transit/index.html), it would bootstrap your application from a small .jar and automatically download and cache any needed libraries from a remote repository.

What would need to be added is signing and verification; authoritative sources (using HTTPS, so that we can trust maven.apache.org or repository.sun.com) so that one will know that the modules have not been tampered with. But if it would be possible to extend the existing Maven repository model for handling large number of Jar-files, it would benefit the whole community (Open Source & commercial projects as well as the JRE).

The nice thing with Maven repositories is also that there are a lot of build tools that interact directly with these.

Nicolai

forax
Offline
Joined: 2004-10-07

Something like that is scheduled for java 7.
see http://weblogs.java.net/blog/stanleyh/archive/2007/06/openjdk_modules.html

Rémi

patrikbeno
Offline
Joined: 2004-10-11

Well, at least size of the download can be effectivelly reduced by pack200. Whole bloated ~44MB rt.jar can be packed into <6MB.

Now imagine we'd manage to split the runtime into multiple separable modules and all packed using pack200 (Except some bootstrap classes and unpacker, of course)

I believe bootstrap with unpacker can be stripped down to 1MB *jar (or even better), and packed core JDK modules would be max 100K-200K each (code size, resources not considered).

Note:
Special approach might be required for charsets.jar (6MB), which won't go below 1.5M. Splitting them into a few groups will help, nobody is using them all at once, I guess

larswestergren
Offline
Joined: 2006-02-20

I think Ethan Nicholas is employed full time by Sun to work on it. Latest info I could find from him is this:
http://weblogs.java.net/blog/enicholas/archive/2006/09/index.html

But even if the goal of a JVM<3mb turns out to be impossible, I think the JSR 277, to break up the JVM into modules that can be loaded as needed would still be a big plus. That one will be in Java7. Latest from techical lead Stanley Ho is here.
http://weblogs.java.net/blog/stanleyh/archive/2006/10/jsr277_early_dr.html

I know this JSR has come under criticism, some people think the expert group has been uncommunicative, but Stanley promises in the comments that they will try to increase the collaboration with the community.

ivanooi
Offline
Joined: 2005-06-27

Thanks for your reply. I really hope that Ethan Nicholas can come out and tell us the latest news about Java Kernel...

Ethan Nicholas, any news lately ? Hope to hear from you soon! Thanks :-D

enicholas
Offline
Joined: 2006-02-27

Officially we're still in the investigation and prototyping phase of this project -- meaning that while work continues on it and we're making great strides, we have not officially committed to shipping it at all, let alone in any specific release of the JRE.

That said, I'm working my butt off on this and the prototype is almost fully functional -- the installer is down to 2.5MB and runs every program I've tested, include enormous ones like NetBeans. Of course it has to download additional code in order to do so, but that's the whole point of the feature ;-). I'd like to get the core code below the 2MB mark for the final release, but it's going to be hard and I'm not promising anything.

When we tested the prototype to determine how much time it was actually saving users (test scenario: download the JRE, install it, and run
SwingSet2) we saw an improvement of between 30% - 50% compared to the current online installer. Of course the savings are purely the result of having to download fewer bytes to get a program up and running -- for some reason a lot of people seem to be under the impression that this will somehow boost their normal Java launch times. It won't. Once the JRE is on your system and done downloading everything it needs, performance should be no different than it always has been.

Again, please don't construe this as a promise that this feature will actually ship. It's penciled in, we've got folks working on it, and we're making good progress, but a lot can happen between now and the release of Java 7.

ivanooi
Offline
Joined: 2005-06-27

Hey! That consider a good news! even though there's no promise on this... but.. still a good news!

Thanks Enicholas!

mikaelgrev
Offline
Joined: 2006-09-27

Ethan,
Would this mean that we can bundle this kernel with our app and ship it? And if we know up front that we're going to need another module, include that as well. If so then I'm VERY excited!

Cheers,
Mikael Grev

enicholas
Offline
Joined: 2006-02-27

> Ethan,
> Would this mean that we can bundle this kernel with
> our app and ship it? And if we know up front that
> we're going to need another module, include that as
> well. If so then I'm VERY excited!
>
> Cheers,
> Mikael Grev

That's the plan, yes.