Do we really need isolate support?
Submitted by epr on Sat, 07/16/2005 - 17:04.
I'm having some second thoughts about our plans for Isolate (JSR121) support.
My main questions:
1) Do we really need it
2) What will we make impossible/very hard once we have it
We have a huge benefit that everything in JNode is in a single address space. It makes everything accessible, but we can still shield of stuff by means of the security manager.
So I'm afraid we'll make our JNode life much much harder if we have a real seperation in terms of (java) address space. E.g. runtime libraries will need marshalling across isolate bounderies in order to reach device drivers. This will harm our performance.
So please respond.
Ewout
- Login to post comments
Yes!
Yes, we really need isolate support. My main reason is to take care of resource isolation issues. It is important to be able to limit anything from JDBC connections to hard drive space to memory use to cpu utilization. However, I think that any OS that can't handle kill completely clean is nothing but a toy. It is also important to be able to change priorities among running processes. I can't speak to how JNode handles kill today (It has been too long since I had it running). Now my requirements don't particularly require isolates support to make work. However isolates provide a clean API to access separate processes programmatically and as such are a useful abstraction.
It is important to add isolate support sooner rather than later. Every feature that is added while the isolate support is not there, will make adding the isolate support just that much harder. Design decisions need to be made with processes in mind. If process support isn't available, most developers won't be thinking about. This will result in an OS API that is not well designed for processes.
I hope the above provides good reasoning for my position.
I have a process spec I wrote years ago for the JOS project. If I can find a way to upload HTML I'll post it.
-Avery
Isolates
Regarding 1):
How are calls to System.exit() currently handled in Jnode? (With isolates calls to Runtime.exit(int) and System.exit(int) will be redirected to Isolate.exit(int) and will only the affect the current isolate, not the entire system.).
Regarding the inter-isolate communication overhead you describe:
The Isolate Specification (j2se_isolate-1_0-prd-spec/docs/index.html) contains the following notes on possible optimizations:
"# Serialization overheads can be eliminated because inter-Isolate communication occurs within a single physical virtual machine allowing for direct manipulation of internal representations.
# In some cases Object copying overheads can be eliminated altogether where the virtual machine is able to provide the illusion of logical copying despite using physical sharing at the implementation level."
E.g. instead of serializing/copying the objects from isolate #1 to isolate #2, the VM could annotate them with a label "this object is used from isolates: #1, #2 [and probably more]". When a field of the object is about to be changed by bytecode executed in isolate #1, a copy of the object would be created (and references from objects within isolate #2 would be turned to the copy) and the label would be removed.
Logically or Actually copying the object to isolate #2 would involve loading its class in isolate #2 and computing and comparing the serialVersionUID of the class in isolate #1 and #2.
Sebastian
'Unbreakable Java: A Java Server That Never Goes Down'
'Unbreakable Java: A Java Server That Never Goes Down' - Very good article at: java.sys-con.com, and SDN.SAP.com: https://www.sdn.sap.com/sdn/weblogs.sdn?blog=/pub/wlg/940
-redany
I think JNode needs
I think JNode needs isolation support. Some time. Realy not now.
I think JNode teams should set some kind of timeline/features order.
I think isolation support should not be primary goal. Not before 0.4...
All above MHO
...boot
Why
Please give me you're reasons for stating that JNode needs isolate support.
Thanks
Ewout
Support these features
Support these features _should_ be added in short/long term feature
1) Multiple versions of classes/plugins working simulateonusly.
Feature needed for truly compatibility with 3rd party applications.
2) Support online JNode VM versions switching.
Personaly I hate reboots. L4Ka microkernel team suggests to build
other microkernel domain, prepare both kernels for switching, and voila, switch to next version.
In case of problems automatic fallback supported.
These features will possibly require support for isolates. IMHO.
We should think about it.
...boot
Version switching
Regarding 2): The Forest project at Sun Labs may be related to this topic. The project aimed "to provide support for all Java(TM) applications manage long-lived, large-scale, complex, shared data" which included evolving instances of classes from one version to the next. The solution they outline would also be applicapable to Java applications running inside Jnode, not only the kernel. However, the project ended after a research prototype was delivered and the results did not make it into J2SE.
Partial solution
The features you mentioned can be achieved by other means also.
1) Solved by classloaders
2) Probably isolation does not help that much
What remains are some statics in the runtime library (the system classes). Maybe we can make isolation work the other way around. Instead of isolating everything, we only isolate what is really needed (like System.in/out/err).
Ewout
Re:
We don't need to isolate everything.
Offtopic: There is (at least) one question remains: what to do with DoS attacks from malicious/"bad behaved" classes? If one class will stress VM/GC by doing too much requests? Did you think about it?
...boot
[Offtopic] about DoS attacks
For me protections against such attacks is related to resource management to protect JNode against too intensive usage of :
- memory
- disk space
- cpu time
- network bandwidth
- network connections
- threads
- ... etc ...
I think that should be implemented later, when JNode will be ready for multi-user, since it's related to such environment but not only. However, that can be discussed now.
Fabien