Overview
As mentioned in other blogs from TechEd, a very impressive live demo was done of a new technology SAP labs has developed; SAP VM Container.
This weblog will hopefully give you more insight into this product and is based on publicly available information I have found. Note that this is not official information from SAP, and it is very possible that I am drawing all the wrong conclusions.
Update 16.11: Please read the excellent official documentation from SAP Labs
Update 26.10: Got an email from someone at SAP Labs working with the Technology saying that they couldn't find any mistakes in the blog
The live demo
For those you who have not attended TechEd this year, I will give a quick recap of the live demo done by Harald Kuck.
The actual application which was shown was a slightly modified version of the Petstore application (which is famous for being used as the comparison of Java and C#). The changes made to the application was that you could cause the application to go into an infinite loop, or crash the Java VM. For some odd reason this wasn't included in the original version.
Three simple webclients were shown which accessed the some part of the application, and basically incremented a session value with one for each call. The webclients looked like vb programs. While the webclients were calling the same function once every other second, a browser session was launched against the browser.
The first function tried in the browser session was the infinite loop. The infinite loop resulted in that the browser was waiting in vain for the server to respond. While we were watching this, Harald attached a debugger to the browser session and started debugging the problem while all the other webclients were running as normal. The loop problem was resolved in the debugger and the browser got the response from the server. The fact that you could debug the request of one user whilst leaving the others in peace was truly impressive. However, in a real production environment you have to ask how big of an overhead are you willing to have in order to be able to debug user processes.
The second function tried in the browser session was the Java VM crash. As expected the browser session just gave an error message, but the other webclients continued running. Normally, when a JVM crashes, it will take down the whole JVM, thereby affecting all users session and batch jobs being processed in it. Also, the JVM was restarted immediately in a blistering 132 ms!
 |  |
All in all a very impressive demo, at least for people familiar with java.
Some extra non-technical information
Being impressed by the demo, and seeing implications far outside SAP Netweaver, I set out to find out more about it. The first thing I did was to do some searches on news.google.com. This gave some hits on information recently released to the press about it.
- Offical press release by SAP
Exert:The key to the new Java functionality of SAP NetWeaver is the Java virtual machine container technology, which allows standard Java code to run on a framework around the Java virtual machine itself. Leveraging new technologies, SAP NetWeaver helps reduce overall memory consumption while improving application stability. This is accomplished by reducing the number of parallel users per virtual machine and hence the number of affected users in the case of an application error. - Article from InfoWorld
Exert: The first enhancement will address problems experienced with some large-scale Java applications, which are vulnerable because a single error can affect many users at once, causing them to lose data or their screens to freeze, according to SAP. By isolating these users' sessions from one another in "containers" in NetWeaver's Java virtual machine (JVM), the company hopes to improve application stability by limiting the impact of errors to a single user session -- reducing the workload for support staff in the process. In addition to its effect on stability, the new JVM framework reduces overall memory consumption for multi-user Java applications, SAP said. The framework also allows administrators to turn on debugging controls for a single user process, meaning that they can identify and monitor errors in a live system, without having to recreate the problem on a test system, the company said. - Article in Computerworld
Exert:"What it means from a user perspective is that the system doesn't crash," Graf said. "We've taken the reliability of SAP and made that capability available in Java." - Article in eWeek
Exert:Two years in the making, the JVM container is essentially a porting of SAP's R/3 kernel technology to Java—a move that should provide developers with the stability of R/3 in Java, said officials of the Waldorf, Germany, company. The container, due next year as part of NetWeaver 2005, enables standard Java code to run on a framework around the Java virtual machine itself, which helps to improve application stability and reduce overall memory consumption.
Not much technical information, but there are two important facts learned:
- SAP has not implemented a new JVM, instead it is making a framework which encompasses existing JVMs.
- It will be released as part of the 2005 Netweaver Stack
At the same time I also found this blog entry from 8 July this year which points to the fact that SAP are looking for JVM developers (the job ad is pulled now).
More technical information
Again, using google I managed to find an old paper called "SAP VM Container: Using Process Attachable Virtual Machines to Provide Isolation and Scalability fo... which was written by Norbert Kuck, Harald Kuck, Edgar Lott, Christoph Rohland and Oliver Schmidt from SAP labs and presented at the 2nd Usenix Java Virtual Machine Research and Technology Symposium in San Francisco 2002.The paper defines Process Attachable Virtual Machines(PAVM) as "a VM that can be attached to and detached from OS processes at very low cost". In order to achieve this, there needs to be a separating layer between the OS and the JVM and it is here the major work is done by SAP.
The SAP VM container uses shared memory in order to create, attach and detach PAVMs. Each PAVM will get its own private part of the shared memory, which is used to contain the heap and stack for the user. The paper also focuses on the aspect of being able to quickly transitioning to and from persistent state. This seems to indicate that the SAP VM container will contains very many PAVMs contained, but very few will be active at the same time. Still it is expected that all the PAVMs are in the shared memory at the same time, so these PAVMs need to be very lightweight.
The SAP VM container is not suitable for all applications that are using java, but is particularly well suited for applications where many users share the same JVM.
The overhead of initializing a new PAVM is rather expensive, but as mentioned at TechEd, this can be avoided by copying the session memory of an allready initialized "master" PAVM. The "master" is initialized when the application starts.
This paper references to JSR 121: Application Isolation API Specification which I decided to look closer at.
JSR 121: Application Isolation API Specification
Java Specification Request 121 is an attempt to specify a java API for how to run independent programs in the same java runtime environment and how communication between them can be done. Each independent program is run inside an isolate, which in SAP's is implemented as a PAVM. The document "Isolates: A New Approach to Multi-Programming in Java Platforms"[pdf] by Ciaran Bryce gives a very good introduction to isolates and the motivation behind them.Some key points are:
- It is not efficient to have as many java runtime environments and OS processes as you have java programs due startup costs and size of the java runtime. Instead, each java program could be an isolate in the same java runtime environment
- An isolate shares no application data or mutable class state with other isolates
- Isolates should have the same level of protection as if they were running runnning in a standard java runtime environment(address space checks and more must be implemented)
- There is no direct sharing between isolates and therefore communication is done using traditional methods as sockets or files (please do not use webservices! ) ,or through links which are part of the API
- JSR 121 says nothing on how the isolates are implemented, it defines an API on how to use isolates from a java program
SAP's Norbert Kuck is a member of the JSR121 expert group and I would expect that SAP's VM container will influence and implement the JSR 121.
At the moment there seems to be three different implementations of the extensions to the java runtime environment needed in order to support the JSR 121 public review version:
- Sun's Multi-tasking Virtual Machine (MVM)
- University of Utah's JanosVM
- SAP's VM container
While the other implementations are mapping M isolates to one java runtime environment, there is information that indicates the SAP's implementation maps M isolates to N java runtime environments.
More information on JSR 121 can be found on http://bitser.net/isolate-interest/
Correspondence
After an inquiry from myself, I also got an email from someone at SAP labs. They said that they are working on documentation to be released outside SAP (I probably need the heavily revise this weblog after it is released). SAP have licensed the source code of an existing JVM, and most changes to it is done in the interface between the SAP VM container and the JVM. What this basically means, is that you cannot plug in any JVM into the container, it needs to be modified first.
Conclusion
I hope you have learned something about SAP's exciting new technology and hopefully most of the information is rather accurate. I would like to stress once more that this information is not official in anyway, it's rather what I made out of the material available.
I expect that there will be some "what's the big deal? we've had this in ABAP for years" thoughts, but coming from the java world this has actually a big impact.
Following the logic of Shai's keynote, SAP might get 6 months or a year's advantage of competitors on this technology, but then it will become a standard for all JVMs. Who knows, after a while we might be back were we started with one OS process pr java runtime environment (but maybe with better OS support and shared memory handling).
7 Comments
