Skip to Content

As part of the SAP NetWeaver Application Server, Java EE 5 Edition SAP now delivers its own Java VM. Find out how to leverage its features!

The SAP Java VM – …

You need to install the SAP NetWeaver Application Server, Java EE 5 Edition in order to get your hands on the JSE 5 certified SAP Java VM (SAP JVM). Please check out my blog SAP NetWeaver Application Server – Reloaded for additional installation hints.

Robust Java Server Architecture

First and foremost the SAP JVM is an integral part of SAP’s Robust Java Server Architecture initiative. If you want to experience Robust Java in action just check out the Car Rental sample. The SAP NetWeaver Application Server, Java EE 5 Edition documentation contains even three Flash movies on building, deploying and running this sample. You can find the link on the Tutorials section or open Demonstrating the Session Failover right here – presuming you have chosen the the default installation location. In case you want to rerun the demo shown in the movies:

  • Regarding Step 1: After building the sample workspace the Problems pane shows 9 warnings and 15 infos. There’s no reason to be concerned about that.
  • Regarding Step 2: There’s no need to locate the mentioned batch file as there’s a Start Menu entry Start Configuration Tool.

Advanced Tracing and Monitoring

The SAP JVM incorporates quite some advanced capabilities for tracing and monitoring. For example the SAPMMC displays the two nodes shown below only if the corresponding server runs on the SAP JVM.

image

image

… – What’s in it for me?

First things first: SAP does not encourage or support using the SAP JVM in any way not provided by SAP. In most cases this will be a show stopper for using it in productive environments. So if that isn’t possible then it doesn’t seem to make much sense for you to invest into using specific APIs for the features described in the sections above. Additionally the APIs in question aren’t documented at all and will definitively change in future releases.

Therefore the sections below will focus solely on using the SAP JVM as a drop-in replacement for the Sun Hotspot VM during the development phase.

What Goes Where

If you installed the SAP NetWeaver Application Server, Java EE 5 Edition to the default location you will find the SAP JVM at C:SAPJP1SYSexe
unsapjvm_5
.

The easiest way to access the SAP JVM is to use the environment variable SAPJVM_HOME added by the installation program in a way like this:

%SAPJVM_HOME% injava

By the way: The reason for the extended startup time of the SAP JVM is that it comes with a Java server compiler only. Starting the Sun Hotspot VM with – server gives you the same behavior.

Improved Full Thread Dump

When running an AWT program and sending a Ctrl+Break to the corresponding JVM console for the full thread dump the Sun Hotspot VM shows the AWT queue handler thread like this:

"AWT-EventQueue-0" prio=6 tid=0x02e7c3b0 nid=0xa38 in Object.wait() [0x0305f000..0x0305fc68] at java.lang.Object.wait(Native Method) - waiting on <0x230d3500> (a java.awt.EventQueue) at java.lang.Object.wait(Unknown Source) at java.awt.EventQueue.getNextEvent(Unknown Source) - locked <0x230d3500> (a java.awt.EventQueue) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown Source) at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) at java.awt.EventDispatchThread.pumpEvents(Unknown Source) at java.awt.EventDispatchThread.pumpEvents(Unknown Source) at java.awt.EventDispatchThread.run(Unknown Source)

Doing the same with the SAP JVM shows the AWT queue handler thread like this including source code line numbers – you’ll get them for all the code coming with the SAP JVM:

"AWT-EventQueue-0" prio=6 tid=0x03903008 nid=0x2c8 in Object.wait() [0x03d2f000..0x03d2fc20] at java.lang.Object.wait(Native Method) - waiting on <0x10771850> (a java.awt.EventQueue) at java.lang.Object.wait(Object.java:474) at java.awt.EventQueue.getNextEvent(EventQueue.java:345) - locked <0x10771850> (a java.awt.EventQueue) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:189) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149) at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)
Improved Error Log Stack Dump

I wrote a simple demo program that creates the call stack main() → javaFoo() → javaBar() → javaFooBar() → nativeFoo() → nativeBar() → nativeFooBar() with the latter function raising an access violation exception.

When running the program on the Sun Hotspot VM then the generated error log file (hs_err_pid????.log) contains a stack dump like this:

Stack: [0x00040000,0x00080000), sp=0x0007fa08, free space=254k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [nativetest.dll+0x1033] C [nativetest.dll+0x1048] C [nativetest.dll+0x1058] j nativetest.nativeFoo()V+0 j nativetest.javaFooBar()V+1 j nativetest.javaBar()V+1 j nativetest.javaFoo()V+1 j nativetest.main([Ljava/lang/String;)V+9 v ~StubRoutines::call_stub V [jvm.dll+0x86401] V [jvm.dll+0xdb172] V [jvm.dll+0x862d2] V [jvm.dll+0x8d2a2] C [java.exe+0x14c5] C [java.exe+0x69cd] C [kernel32.dll+0x16d4f]

In contrast the SAP JVM error log file contains a stack dump like this:

Stack: [0x00040000,0x00080000), sp=0x0007fa38, free space=254k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C nativetest::nativeFooBar - nativetest.c:5 C nativetest::nativeBar - nativetest.c:10 C nativetest::Java_nativetest_nativeFoo - nativetest.c:16 j nativetest.nativeFoo()V+0x0 j nativetest.javaFooBar()V - nativetest.java:10 j nativetest.javaBar()V - nativetest.java:14 j nativetest.javaFoo()V - nativetest.java:18 j nativetest.main([Ljava/lang/String;)V - nativetest.java:23 v ~StubRoutines::call_stub V jvm::AsyncGetCallTrace+0x3d7c6

You may have guessed by now that the SAP JVM will show the source code line numbers for the Java functions, but I presume that you are at least a little surprised to find source code line numbers for the native code functions too!

The SAP JVM accomplishes that by looking for a .PDB file containing debug symbol information in the same directory the native code .DLL file was loaded from. As this is just the place the Visual Studio linker puts it by default and the Visual Studio debugger looks for it too the SAP JVM is typically able to provide those line numbers out of the box – as long as you build with debug symbols.

Just-In-Time Native Code Debugging

The Sun Hotspot VM hides access violation exceptions (and in fact all Win32 exceptions) from Windows. While it may arguable if this makes sense for productive server machines it is certainly an issue for native code developers. The SAP JVM on the other hand propagates Win32 exceptions in the ordinary way to the registered unhandled-exception handler – which brings up the message box below if the Visual Studio debugger is installed.

image

Selecting Cancel launches the Visual Studio debugger allowing you to break right into the source code line that raised the exception as shown below. The error log file generated by the SAP JVM is already present at this point so you can refer to it to find out about the Java context of the exception.

image

Java Debugging on Demand

Normally you have to decide on Java VM startup if you want to potentially debug code running on this VM. In opposite to that the SAP JVM allows you to switch to debug mode on the fly. For SAP NetWeaver this is normally done in the SAPMMC but the SAP JVM comes with a menu driven text console program which does the same. You can run the JVM Monitor in a way like this:

%SAPJVM_HOME% injvmmon

First select the Cluster Menu and then Start Debugging. This causes the VM to print out a message like this on the console and wait for the debugger:

Listening for transport dt_socket at address: 8000

Now you can attach your debugger as normally to the port number given. In case you shouldn’t be able to read the message you can obtain the port number as well by selecting Display VM list in the JVM Monitor as shown below.

image

Wrap Up

Although the SAP JVM is primarily intended for use with SAP NetWeaver it may very well help you in your day-to-day development with its improved diagnostic and debug features – so go ahead and give it a try!

To report this post you need to login first.

4 Comments

You must be Logged on to comment or reply to a post.

    1. Oliver Schmidt Post author
      Hi Bernd,

      Regarding Isolation and Shared State: The document ‘SAP’s Approach to Robustness and High Availability’ mentioned in the blog covers those aspects in great detail so I opted to refer to it instead of repeating its content here.

      Regarding availability: My assumption is that the SAP JVM will be an integral part of all SAP NetWeaver Web AS releases being certified for J2EE > 1.3.

      Hope that helps, Oliver

      (0) 

Leave a Reply