Skip to main content

Isolation API in JDK7?

37 replies [Last post]
atus
Offline
Joined: 2005-06-16
Points: 0

Hello fellow developers,

A feature that I really wanted to see in JDK5, which was skipped again in JDK6, is the Isolation API.

(In short, this feature makes it possible to run multiple Java programs in one JVM. E.g. the JVM could start as a service at boot time, making all Java program startups instantaneous. Memory consumption would reduce too. This would probably be the last step to make Java app(let)s feel native.)

Ever since this feature got dismissed from JDK6 (and I still remember the sad day it was announced on Chet Haases's blog), I haven't heard of it :-(

I was wondering, what is the status of implementing the Isolation API in JDK7? I hope the silence isn't because it got canceled altogether. Let me know, anyone! Also, if you know of any good quality 3rd party implementation, don't hold the info back! Thanks.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
mthornton
Offline
Joined: 2003-06-10
Points: 0

> There
> are also other features missing such as being able to
> have more than one version of your software using
> Webstart.

I set up webstart such that minor versions just update the JNLP file and jar files, while major versions have a new JNLP file which refers to the updated jar files. Then it is just a matter of crafting the web page to allow easy selection of the desired version. Users can then have any or all of the major versions available, and 'update' when they choose. Resources which don't change between versions are shared, with versioned resources and jardiff, then download for a new version is minimised.

When you create a new major version, you can also update a resource in the older versions which lists the newer versions available.

dutchiedave
Offline
Joined: 2004-05-12
Points: 0

Hi,

It is good to know that there are incremental update between versions of java with the same base(say bewtween 1.4 update 7 and update 9, although it looks like that is for windows only and also not between say 1.4 and 1.5 but it is a good start).

But your comment "Remember that the majority of the world runs off dial-up connections. A 2MB JRE downloads in 11 minutes, a full-fledged 7MB JRE in 38 minutes. Can you honestly see anyone downloading anything for that long as a *pre-requisite* for running something that could be conceivably as simple as Java Notepad?" misses the point. Would anyone write applets anymore if some of the public had to wait up to 28 minutes(7MB) just to view a webpage even if the user had Java pre-installed. The Java Kernel will not make Java look more responsive, it will make it look worse it most cases. Or if it does I cannot see it and no-one can explain it.

More important to rememeber is that Java comes pre-installed on most computers and Java comes with auto-update which means it is highly unlikely that someone would suddenly have to download 7MB just to view JNotepad.

It is far more likely that every time someone views an applet they will have to wait an unacceptable time for a webpage to view the webpage properly. It is also far more likely that every new Java application a user runs will result in a long wait to download the missing pieces of Java from the internet.

Dave.

cowwoc
Offline
Joined: 2003-08-24
Points: 0

Look, applets are dead. I really don't feel there is any value in discussing them as a use-case because I don't think there is any interest in the Java plugin. The problem with applets has more to do with the load-time of the plugin and usability concerns (applets steal the keyboard focus, etc) than it has to do with the JRE download size.

Java desktop applications, on the other hand, are a thriving new industry and their main problem has more to do with ease of deployment than it does with load-time. People seem to have more patience for desktop applications loading slowly than they do for slow websites.

Gili

dutchiedave
Offline
Joined: 2004-05-12
Points: 0

Hi,

I have been using webstart since it first appeared and use it quite a bit for deployment but the arguments for applets are just as true for a webstart application or even standard java applications.

It still stands that anyone who runs an applet/application/webstart program will have to download the missing pieces of java. This will most likely be bigger than the new program itself and the amount of time the user will have to wait will be totally unpredictable. Some people may think that this is a better user experience but i think many would not.

Most computers have java preinstalled so they only have to download the applet/webstart code to run the new program they want to run. If they don't have java installed they will have a once only wait, which will be longer than with the concept of the Java Kernel but they won't have to wait every time they run a new java application. Also if they run an application from say a CD there is every chance they will have to connect to the internet to download the missing pieces.

The question is how is the user experience going to be better and is it actually worse?

Also, I personally believe that there are far more important features with respect to deployment with Java that should be a priority, some which have been waiting for quite a while to appear. One example being fine grained security for webstart. I hope Sun's limited resources can stretch to fixing the issues with deployment and are not eaten up doing the Java Kernel.

On a side note I also hope that computer manafacturers who put Java on the computers they sell don't use the Java Kernel or the user experience for the majority will take a major step backwards.

Sun and their developers have done a great job with Java and Webstart. I just hope that the user experience does improve and the missing feature with deployment are actually addressed.

Dave.

cowwoc
Offline
Joined: 2003-08-24
Points: 0

1) If Java Webstart can estimate the remaining download time, why do you assume you wouldn't be able to do the same with Java Kernel?

2) Java Kernel will reduce the perceived memory usage of Java applications because less is being memory-mapped because rt.jar and friends start out much smaller. Though admittedly, this is probably less an issue today than it was back in Java5 because of http://weblogs.java.net/blog/xiaobinlu/

3) If you argue that Java Webstart provides a better user experience then I really don't see how you can argue Java Kernel will be any difference since the latter is simply an extension of Java Webstart, allowing download of system classes on demand whereas previously we could only do it for user classes.

4) The fact of the matter is, more and more people get security-related prompts when they download binaries. FireFox does it, Windows XP and Vista certainly do it and so when Webstart does it too it's really not such a big deal anymore because people no longer read the dialogs they just click OK all the time. Yes, I agree with you that finer-grained security is sorely lacking. I just disagree with the priority of the two features :)

5) Manufacturers who preinstall Java on their computers and/or applications that ship on CDs should always include the full JRE on it. It really makes no sense to do otherwise. That said, think of a full JRE as Java Kernel with "eager" dependencies. You should always be able to ship Java Kernel with as little or as much pre-installed components as you want.

I (would like to) think that most of us agree these are good features but we simply disagree as to their priorities and which order they should come in. Hopefully with open-source Java one of the first things that will improve will be the Java Webstart experience.

Gili

dutchiedave
Offline
Joined: 2004-05-12
Points: 0

Hi Gili,

In response to:

1. It is not that Java Kernel won't be able to estimate the time to download it is that the developer won't know how much of Java is missing on the end user's computer thus the developer can't estimate the time for the download and to develop the software accordingly and also inform the user before starting the download process.

3. The main point I am making is there is a major difference between Webstart and Java Kernel. The end user will have to download the missing pieces of Java at the time of running the application. This extra wait could be significant and this will taint the user experience more than anything else. It will make Java look less responsive which is the biggest problem in the first place adding to any percieved slowness in startup time.

4. I'm glad you agree on fine grained security. There are also other features missing such as being able to have more than one version of your software using Webstart. I'm not sure about the fact people just click through security dialogs, they might from websites they trust very well but it is a certain recipe to destroy your computer to do so generally, and shouldn't be encouraged.

I guess I don't really see where the advantages of the Java Kernel are and I can see significant diadvantages. It seems the only advantage is a smaller initial download for the JRE at the expense of waiting and downloading missing pieces when running a new Java applet/webstart/application. I suppose it comes down to whether you would rather wait a determined amount of time once or whether you would rather wait less time intitially and then some undetermined time at run time. With Java pre-installed on most computers and with auto-update for Java downloading new versions of Java at convenient times I know which i prefer but i appreciate other people have different preferences.

I appreciate your responses,

Dave.

cowwoc
Offline
Joined: 2003-08-24
Points: 0

3. I simply don't agree. When Windows Media player says "downloading codec" people don't complain. It seems as if this is a *feature* for downloading components automatically in order to save you time. The same goes for FireFox plugins.

I think whether users are happy or upset at this feature is purely a presentation thing. If it is well presented it'll be accepted just fine. Also you are confusing "startup time" with "download time" which are two completely different issues. Users understand downloading takes a while (even on DSL) but what they don't accept is that a local application take a while to launch, which won't be the issue with Java Kernel. If you integrate Java Kernel with Java Webstart it could automatically include the JRE components in the list of dependencies to download and so from the user's perspective it'll take X minutes to download this application.

5) Another great side-effect of Java Kernel is that it will give Java room to grow. Currently there is a lot of pressure on Sun to stop adding components into the JRE because it is getting bloated. Java Kernel should relieve some of this pressure which is a good thing in its own right. Developers have been trying to ship private-JREs for years but have been restricted due to legal constraints in Sun's license. This will allow those same developers to ship a JRE with the benefits of a private JRE while meeting Sun's legal demands.

Gili

coxcu
Offline
Joined: 2003-06-11
Points: 0

While I really hope JSR-121 will be part of Java SE 7, it is almost completely unrelated to the "Java Kernel" concept. Modularity in the form of JSR 277/294 looks like it will definitely be a part of SE 7. Changing the JRE to take advantage of these new features will be essential for a more modular JRE. Indeed, delivering a JRE that supported 277/294, but didn't use them would be like delivering a JDK with a compiler that supported generics and standard libraries that didn't. It's technically possible, but doesn't say much for your faith in the idea or how thoroughly it has been tested.

I'm not saying that the "Java Kernel" concept should be implemented. I don't really have an opinion either way. The bulk of the work it would take to support it, however, is likely to be done for other reasons.

cowwoc
Offline
Joined: 2003-08-24
Points: 0

Dave,

Incremental updates already exist. As for Java Kernel, it doesn't force you to ship a stripped down JRE and install components later, you could specify components need to be downloaded eagerly, as Java Webstart already offers. So in a nutshell: Java Kernel gives you the *option* of shipping a bare-bones JRE, it doesn't force you to do so.

Remember that the majority of the world runs off dial-up connections. A 2MB JRE downloads in 11 minutes, a full-fledged 7MB JRE in 38 minutes. Can you honestly see anyone downloading anything for that long as a *pre-requisite* for running something that could be conceivably as simple as Java Notepad? Also, Java Kernel resolves recent flamewars about which components should be bundled with the JRE or not and the JRE becoming too bloated. This solution should make everyone happy.

Gili

cowwoc
Offline
Joined: 2003-08-24
Points: 0

Sun's documentation for class sharing can be found here: http://java.sun.com/j2se/1.5.0/docs/guide/vm/class-data-sharing.html

IBM's documentation can be found here: http://www-128.ibm.com/developerworks/java/library/j-ibmjava4/

IBM already allows any class to be shared across multiple JVMs and they document how startup time and memory usage drops with class sharing enabled.

I remember reading that Class Sharing was supposed to be improved for Java 1.6 to allow sharing of any class, like IBM's JVM, but it looks like that never made it into the final release. Also I found http://www.theserverside.com/news/thread.tss?thread_id=25010 which hints that the Isolation API would ship with Java 1.6 but it was dropped too.

Can someone in Sun please comment on this?

Thank you,
Gili

coxcu
Offline
Joined: 2003-06-11
Points: 0

JSR-121 doesn't dictate implementation. See:

"Implementation Styles:
One Isolate per OS process
Internal sharing via OS-level
shared memory, comms via IPC
class representations, bytecodes, compiled code, immutable
statics, other internal data structures
All Isolates in one OS address
space / process
Isolates still get own versions of all statics/globals
including AWT thread, shutdown hooks, ...
Isolates scheduled onto JVMs
LAN Cluster JVMs
Isolates on different machines, one admin domain."
http://bitser.net/isolate-interest/slides.pdf

"Increasing the Robustness of the Java Virtual Machine"
http://developers.sun.com/learning/javaoneonline/2005/coreplatform/TS-71...

alexter
Offline
Joined: 2006-11-10
Points: 0

Looks like I have to apologize to java, my machine and everyone for my words about "20 apps". I'm now running 15 java applications (each in it's own JVM, of course) + a bunch of native ones I constantly use. Nothing terrible happens. The machine is as responsive as usual. While part of these apps are lightweight demos, others are pretty heavy. I'm using Sun JRE 1.6.0 beta2 on WinXP.

Memory consumption is pretty high, but I think this is the case when the most objective measurement is subjective feeling.

Alex

coxcu
Offline
Joined: 2003-06-11
Points: 0

See also:

"Poor man's Multi-VM"
http://blogs.sun.com/chrisoliver/date/20061129

cowwoc
Offline
Joined: 2003-08-24
Points: 0

Alex,

1) Java Kernel is aimed at making Java deployment more seamless for desktop users. Think "Flash Plugin" which is a tiny 2MB download which installs seamlessly in the background without you even noticing.

2) As for the Isolation API and shared memory you must remember that since Java 1.5 we have class sharing so some classes are only allocated once in memory no matter how many JVMs you have running. I believe class sharing is scheduled for improvement so it'll work even for user-defined classes and I think that's already in Sun's schedule for improvement. If that's all you want maybe that's what you should be pushing for more directly (as opposed to the other features the Isolation API bringS).

Gili

alexter
Offline
Joined: 2006-11-10
Points: 0

Gili,

Thanks for clarification! In fact I didn't know about class data sharing. Of course I welcome any solution that makes desktop apps deployment and usage smoother.

I've just looked at JSR 121 once again. The features isolation API seems to provide in addition to resource sharing are controlling(at least starting/stopping), monitoring and communication. I once had a need for all three, but it still doesn't seem as important as better user experience.

So, if the inter-JVM resource sharing is something more realistic and is more likely to be delivered soon, just tell me how to push for it and I will push :)

Alex

dutchiedave
Offline
Joined: 2004-05-12
Points: 0

Hi all,

In repect to the Java Kernel and it's aim to improve the end user experience. The desktop user experience definately needs improving but installing the bare bones of java and then downloading the rest as needed will not improve the user experience at all. It means when a user views a webpage with an applet the user will have to download the applet and all the missing pieces of java that they don't have. This will actually cause the user to wait considerably longer and make java look less responsive, which is exactly the problem it is trying to solve. If everyone only had the Java Kernel version of java it would destroy the use of applets.

The number one priority for a better user experience i believe is to make updating your version of java quicker by only downloading what has changed between versions. For instance going from Java 1.5 Update 7 to Java 1.5 Update 9 involves downloading the entire JRE again. Surely this can be avoided thus making updating java a small (<2MB) download while making applets and all java applications responsive by having all of java ready to go at all times. Most computers these days come with a recent version of Java installed so this would solve any user experience problems about file size and downloading.

Dave.

trembovetski
Offline
Joined: 2003-12-31
Points: 0

> by only downloading what has changed between versions.

Um, I believe that this happens already:
http://weblogs.java.net/blog/stanleyh/archive/2005/05/deployment_unde_1....

Dmitri

mernst
Offline
Joined: 2005-02-19
Points: 0

> From that perspective, for the JRE, why
> not just use processes and run a separate instance of
> the JRE in each of those processes?

> memory savings, quicker startup time, reliable forced
> termination of rogue apps, or is it something else
> altogether?

For me, it's the reliability aspect. I want to load some code, talk to it, let it run for a while, and then stop it again. And I want said code to be unable to plant an endless loop or a memory leak into my process - not even voluntarily, it's just too easy to make such mistakes. An unsolved problem in Java (Eclipse recommends a restart after plugin removal, Webcontainers regulary run out of memory if you redeploy a webapp multiple times.

If you can come up with a library that makes this easy and reliable enough enough on top of multiple OS processes (easy setup of child process, fast and reliable communications channel, reliable notification of death, reliable termination) it's probably fine for certain problem classes with tens of instances.

The problem of startup time is inherently coupled to your process model. You still need to design your processes to rarely start/die and be multi-threaded internally. A process-per-request model is out of reach. How does class data sharing work anyway? Could one exploit it for the application classes as well?

Note that a system like Eclipse probably requires tighter coupling since their plugins exploit rather rich and chatty API boundaries. JSR 121 message passing style would be rather painful, CLR's cross app-domain proxies much more comfortable. I have no idea how fast a cross app-domain call in .NET is.

Matthias

mlam
Offline
Joined: 2006-10-13
Points: 0

Hi everyone,
I was just wondering what actual features (in terms of isolation / Java Kernel) do people need and why (i.e. your motivation for wanting it)? When I think of isolation, I think of the properties of an OS process with all the benefits and problems inherited from that. From that perspective, for the JRE, why not just use processes and run a separate instance of the JRE in each of those processes? I know that this approach is naive. But I'm trying to understand what feature it is that you actually want. Is it the memory savings, quicker startup time, reliable forced termination of rogue apps, or is it something else altogether? Thanks.

alexter
Offline
Joined: 2006-11-10
Points: 0

mlam,

The answer is very simple. The only thing we hunger for is better user experience with java desktop apps. I don't really care how it's going to be achieved.
Reliable forced termination of rogue apps is worthless by itself. But it's vital for a real isolation, which is needed for lower memory consumption and better startup time. While writing this, I have 20 "applications" open. If each would be a separate JVM, I don't think my machine could stand that.
I have seen the "java kernel" term on this thread for the first time, but I guess it stands for the ability to download only a part of platform libraries, which a particular app requires. The only intension of this is to reduce download time thus improving user experience.

Alex

mthornton
Offline
Joined: 2003-06-10
Points: 0

> this, I have 20 "applications" open. If each would be
> a separate JVM, I don't think my machine could stand
> that.

It might if there was more extensive sharing between JVMs.

mthornton
Offline
Joined: 2003-06-10
Points: 0

Some of those Java objects may be wrappers for OS resources and these too are liable to be in an inconsistent state. In most OS this can only be cleaned up by killing the process (and of course in Windows 9x even that may not suffice).

Now you could conceivably wrap such objects in further layers and prevent Thread.stop from interrupting native code (which may be undesireable if that is where the app is stalled), and track ownership of these at the isolate level. Once you have done all of this the overhead may approach or even exceed that of creating a new process.

coxcu
Offline
Joined: 2003-06-11
Points: 0

"Once you have done all of this the overhead may approach or even exceed that of creating a new process."

What kind of overhead are you talking about? Do you mean the amount of code that needs to be written, or the performance? In my experience, creating a new Java process and transferring objects between JVMs on a single machine via RMI is more than fast enough for most things. Unfortunately, creating a new JVM is a platform-specific act that involves lots of fiddly details.

As far ease-of-use, I would like to see the following methods added to Thread.

/**
* Return a new Thread that can safely be stopped.
* Any action that would prevent the thread from being
* safely stopped will throw an
* IllegalThreadStateException rather than being executed.
* Thus, code that executes on a normal thread might
* fail on a safely stoppable thread.
*/
public static Thread newSafelyStoppable(Runnable r);

A similar method to support the easy execution of a Callable in another JVM would also be very useful. Of course, for many things, Threads and Runnables are too low-level. The equivalent remote and safely-stoppable Executors would be useful there.

Those would be more useful to me than isolates.

cowwoc
Offline
Joined: 2003-08-24
Points: 0

Actually I'd like to inject a point that might be in coxcu's favor. I once wrote an application that injected itself into a remote process space (explorer.exe to be specific) and launched a JVM inside there. The problem, you see, is that there is no way to terminate a JVM without killing the entire process it's running in (see JNI_DestroyJavaVM()). Now, by implication, any time I wanted to uninstall my application, I'd want to remove its DLLs, which by extension meant I had to shut down my code running inside explorer's process-space which by implication meant I had to kill the JVM... and it took down Explorer with it.

All I'm trying to say is that as part of this Isolation API you're probably going to have to fix JNI_DestroyJavaVM() work such that it doesn't kill the process it's running in. In fact, there has been a bug report open against that for around 10 years I think, but it hasn't worked its way up the priority queue.

Some other side-effects you'll notice is how the Java Plugin refuses to close until you exit the entire Web Browser because fundamentally it *can't* because killing that JVM would require killing the entire browser process, etc.

So, I am actually in favor of JNI_DestroyJavaVM() finally getting fixed (it probably involves removing a whole bunch of global variables). And by implication this probably also means that you will be able to launch multiple JVMs per process and kill them independently of one another and this will help the Isolation API as well.

Gili

mthornton
Offline
Joined: 2003-06-10
Points: 0

Unfortunately the problems which caused Thread.stop() to be deprecated can't easily be fixed within a process. It isn't a Java problem, but a more fundamental problem at the OS level. Essentially in a typical OS, if you wish to reclaim resources used by the dead thread you have to kill the process as well (lets ignore those OS where it takes a full reboot!).

coxcu
Offline
Joined: 2003-06-11
Points: 0

mthornton,

While there are OS-level issues, this is a Java problem.

"Why is Thread.stop deprecated?

Because it is inherently unsafe. Stopping a thread causes it to unlock all the monitors that it has locked. (The monitors are unlocked as the ThreadDeath exception propagates up the stack.) If any of the objects previously protected by these monitors were in an inconsistent state, other threads may now view these objects in an inconsistent state. Such objects are said to be damaged. When threads operate on damaged objects, arbitrary behavior can result. This behavior may be subtle and difficult to detect, or it may be pronounced. Unlike other unchecked exceptions, ThreadDeath kills threads silently; thus, the user has no warning that his program may be corrupted. The corruption can manifest itself at any time after the actual damage occurs, even hours or days in the future."
http://java.sun.com/j2se/1.5.0/docs/guide/misc/threadPrimitiveDeprecatio...

The issue is leaving Java objects in an inconsistent state. It might be possible to use ClassLoaders and bytecode engineering to implement threads that can safely be killed--but I don't think it is practical.

cowwoc,

Some form of voluntary stopping is enough if the code:
1) has been written to honor it
2) works as designed

Making an attempt at #1 isn't too hard (although often not done), so standard API support would be nice. #2 is essentially impossible to guarantee under all circumstances. The proper course of action for stopping a thread or process is:

1) Ask it to stop.
2) If it doesn't stop within a reasonable time, force it to stop.

If your threads are always well behaved, then being able to force them to stop is useless. For a program that uses or accepts third-party code, guaranteeing their actions is essentially impossible. IDEs, webservers, and browsers are obvious examples, but anything that supports a plug-in architecture which allows code to be executed faces this problem.

cowwoc
Offline
Joined: 2003-08-24
Points: 0

Well.... Here are some thoughts:

1) Even if we fix the Java issue you mentioned, it is still OS unsafe so why bother?

2) Your point about anything with a plugin architecture (webserver, etc) requiring this functionality is a very valid point. What would happen if you use JNI to kill this thread behind Java's back...? Probably bad things but I'm just curious.

Gili

alexter
Offline
Joined: 2006-11-10
Points: 0

There's a much easier solution of the problem than fixing Thread.stop(): just deprecate and then remove System.exit() ;-)
Just kidding :)

caclark
Offline
Joined: 2005-02-24
Points: 0

I have to agree, Gili...

I have seen attempts to circumvent normal behaviour to create a java environment in which multiple Java apps can run without the overhead of:

(1) Startup time
(2) Process memory

Echidna was a (well fought) attempt to try to get the Java VM in line, and I have noticed that it is made quite a bit easier regarding low-level APIs with the introduction of Java Instrumentation (re-assigning class byte codes at load time). This means that you can create your own java.lang.System, java.lang.?Whatever? classes by reinstrumenting the byte code.

However, there is a fundamental problem regarding the way that Java is specified, and that is that the stop () method of java.lang.Thread is deprecated, and therefore should not be used. Attempts to create a unified Java environment have come up with this problem. I guess U**x or l**x users will say 'what's the problem?' as they are used to Apache forking off processes like they are going out of fashion... but Java would really benefit from a one-process, multiple applications approach.

So it requires a Java application monitor - and it also requires a 'master thread' approach. But, we have now a chance to reconsider the Java architecture with the new licensing... many thanks to Sun for investing a heck of a lot of energy in VM technology, maybe it is now time to invest on a sort of 'Hyper VM' technology, that can run applications as a thread within the master process.

Or maybe another approach... load balancing ... maybe having three java processes that are using memory stored on disk - because I do realise what happened with IE. When Internet Explorer crashed on my machine, all the windows went with it.

So in the end - process load balancing, and master-thread application instances. Go for it? I'm sure that there are some serious people out there that have even *better* ideas, but this might for once be the REAL Java 2 :-)

cowwoc
Offline
Joined: 2003-08-24
Points: 0

caclark,

Don't get me wrong, I'd be quite happy to see someone implement both Isolation API *as well* as Java Kernel in Java7. I'm just saying that if I personally had to choose between the two, I would choose the latter.

Out of personal interest, why do you even need Thread.stop()? In my personal experience, using a "shutdownRequested" field in a Thread or Runnable has always worked very well for me. Why does this workaround not work for you?

Gili

alexter
Offline
Joined: 2006-11-10
Points: 0

Gili,

I guess the answer is that the stop() method would be very useful to emulate isolation on top of current API. This isolation library would need some way to terminate threads it has launched. Recently I had a need to terminate an alien code running in the same VM. And guess what? I had no other choice but to call ThreadGroup.stop(). I know it's crime :)
Reading this thread was very disappointing: mistakenly I was under the impression that both isolation and "kernel" are coming very soon and taking us to a better world :). And you guys say it's totally false :(

Alex

caclark
Offline
Joined: 2005-02-24
Points: 0

It is great to see so much feedback about what is in essence a complicated topic now that the JVM has so much become a one process one application concept for most platforms.

The opensourcing of the JVM will create a great opportunity for greater minds than myself to consider how one thread one application subprocess management can be maintained across diverse platforms. I have already seen all the efforts of folks around to remedy this situation.

I looked at the Xito platform and noticed that it was grabbing the application thread, and first interrupting it and then resorting to stopping it. The old Echidna codebase was just using a stop method.

The new developments in the instrumentation API (JDK 5+) also create a new realm of possibilities in MVM, because it actually gives shrewd developers the chance to override core libraries and delegate to the defaults when needed. This I consider a boon on the path to the shared VM.

Take, for example, the chance using an agent to replace the various IO classes (File, FileReader, FileWriter, etc.) as an alternative class MyFile, MyFileReader, MyFileWriter, that can behave in a special way, and delegate to the original classes using correct agent configuration.

Maybe the opening of the JVM will get some great minds to think about how a thread-per-application system can be done well. This has to be taken seriously, of course, because industrial use of such a module will create a single point of failure (the VM process instance), and also make it more complicated to maintain individual subprocesses. But in the case of the latter, the Xito folks have already been doing some hard thinking on that.

Chris

cowwoc
Offline
Joined: 2003-08-24
Points: 0

... not to poo poo all over someone else's ideas but I personally prefer seeing Java Kernel released as part of Java7 as opposed to an Isolation API (assuming we can't have both).

In my view, deployment on desktop computers is a much bigger problem for Java than memory or startup time, and by deployment I am referring to a small download size and ease of installation.

We know for a fact that the majority of the people in the world run off dial-up internet connections, but can you make a similar point about the amount of memory they have in their computers and whether it is the prime factor preventing them from installing and retaining Java applications? Yes, I sometimes hear people whine about Java's memory usage as a reason for why they steer clear of Java, but far more often I see people using applications if they're good without the slightest understanding about how they work under the hood (Java or otherwise). If applications install JVMs seamlessly when they're missing then we'll be much better equipped to target the desktop user. I feel Java Kernel is the best solution for this and a few other problems. Just my 2 cents.

Gili

coxcu
Offline
Joined: 2003-06-11
Points: 0

While JSR-121 implementations could have an impact on startup time, many JSR-121 proponents aren't looking for that. An implementation based on ProcessBuilder would be just fine for me. The benefits are:
- a simple, standard, cross-platform way for one JVM to start another one
- a way to safely kill a thread

Few small applications need either of these facilities. Many large applications need both.

bharathch
Offline
Joined: 2004-02-16
Points: 0

At a time when great proclamations are being made of new avenues opening up with openJDK, the Barcelona project and the Isolation API have been languishing in the experimental phase for eons. Meanwhile, .Net which came *years* after Java (and has features decided upon unilaterally without a community process), already has application domains - the concept that multiple applications can share a single CLR process. You can kill one application independent of another application by killing the launcher that invoked the CLR host.
While .Net has made such progress, the MVM project is still labouring along, its principal investigator isn't with Sun any more, and no one knows where the project is headed.
Some progress, this.

spdenne
Offline
Joined: 2006-02-15
Points: 0
atus
Offline
Joined: 2005-06-16
Points: 0

Hello!

Yes, I have seen the specification and I got the Javadoc, but does anybody know when it is going to be actually integrated into JSE / JDK, or at least as a downloadable supplemental package?