Skip navigation.
Downloads | Product Documentation | Support

Developing Java Applications

# Troubleshooting

While the process of switching to BEA JRockit 1.4.2 JVM from another JVM is relatively easy and generally problem-free, you might encounter some known issues while or after making this switch. This section describes some of those issues and describes some simple workarounds. The issues that might occur are:

- An Application Does Not Run
- Slow-to-Start Applications
- Process Counter Does Not Initialize
- Large Memory Consumption
- Slow Performance vis-a-vis HotSpot
- Randomly Appearing Bugs
- BEA JRockit JVM Throws Errors HotSpot Does Not Throw
- Slow Performance in Development Mode
- BEA JRockit JVM Does Not Run Jakarta Tomcat as a Windows Service
- Other Frequently Asked Questions

# An Application Does Not Run

I cannot get my favorite Java application to run on BEA JRockit JVM. What am I doing wrong?

Many problems with running applications on BEA JRockit JVM is due to erroneous environment variables or non-standard startup options.

Start by ensuring that your environment variables are set up correctly. Make sure that you have set your `JAVA_HOME` environment variable correctly, i.e. set to the directory where BEA JRockit JVM has been installed, and that `"%JAVA_HOME%\bin"` is available in your `PATH` environment variable before any other directory where any version of java.exe may exist. When running applications as Windows services it is crucial that you set these environment variables system wide. To do this:

1. Open the Start menu and select Settings>Control Panel>System
2. Select the Advanced tab.
3. Click Environment Variables.
4. To set system wide environment variables you must edit in the lower part of this dialog box, labeled System variables.

Applications are often started via scripts. Make sure that none of the startup scripts includes non-standard startup options for java. See Tuning BEA JRockit JVM for complete documentation of standard and non-standard options.

# Slow-to-Start Applications

Why does it take longer for my applications to start with BEA JRockit JVM?

Java programs are compiled into byte code by a Java compiler. Many JVMs, including the Sun JVM, interprets this byte code each time it is executed. BEA JRockit JVM, however, uses code generation technology to generate native machine code from the byte code. This is sometimes called Just-In-Time (JIT) compilation. The code generation step imposes an initial time penalty before execution. Normally, the subsequent execution of the code is faster than interpreting the byte code. BEA JRockit JVM is optimized for server applications that normally run for long periods of times. The initial time penalty is normally negligible in comparison to the performance gains of code generation over time.

# Process Counter Does Not Initialize

Sometimes, when running BEA JRockit, I encounter a NotAvailableException when the console tries to connect to JRockit or if the program itself tries to access the CPU load counters.

Occasionally, the process counter does not initialize. This happens only on Windows installations where either the security settings are such that the Performance Data Helper (PDH; a Windows API that reads performance metrics from the operating system) process counter can't be read or where, for reasons unknown, the PDH process counter is simply turned off. This will deny you the rights to look at the process counter and throw the error. You will receive this message:

>     JRockit] WARNING:  Could not initialize the virtualbytes counter, some
>     functionality in jrockit.management.Memory will not be available. Message
>     was: failed to  create counter query. String was: (null)\Virtual Bytes

>     [JRockit] WARNING:  Could not initialize the JVM process load counter, CPU
>     load generated by the JVM will not be available. Message was: failed to create
>     counter query. String was: (null)\% Processor Time

Why the process counter is turned off is unknown; however, should you encounter this situation, you can turn it on again by following the instructions at this location:

>     http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/
>     exctrlst-o.asp

If that doesn't work, check your security settings and then make sure the performance counters can be read using the Windows perfmon tool, running as the same user that the JVM process is running as.

# Large Memory Consumption

Why does my applications consume more memory when running on BEA JRockit JVM?

The Java programming language relies on a mechanism called garbage collection (GC) to free memory when it is no longer being used. There is no equivalence to the `delete` operator in the C++ programming language or the `free` function in the C programming language. Any Java virtual machine must include a garbage collector that handles the task of finding unreferenced objects, possibly invoke their finalizers and free the memory used to hold their state.

The BEA JRockit JVM garbage collectors are described in Selecting and Running a Memory Management System in Using BEA JRockit DK. Generally, the BEA JRockit JVM garbage collection implementations trade high memory usage for speed and minimal program wide halts; that is, acquiring system wide locks.

# Slow Performance vis-a-vis HotSpot

I have a script/program that use BEA JRockit JVM for certain tasks. Why is it slower than when I use the Sun JVM, HotSpot?

This might be related to the Slow-to-Start Applications above. Scripts or other programs may start many Java processes and may therefore experience bad performance compared to the Sun JVM, since BEA JRockit JVM has a code generation penalty when starting up. When starting many Java processes and running them only for a short time, this penalty can become significant.

# Randomly Appearing Bugs

Why does my application have randomly appearing bugs when running on BEA JRockit JVM that it doesn't have when running on the Sun JVM?

You may be experiencing synchronization bugs in your application. It is not uncommon that such bugs are revealed when switching JVMs. The JVM specification and the Java language specification leaves plenty of room for optimization that may cause unsynchronized access to shared data, to cause different behavior on different JVMs.

For more information see:

http://java.sun.com/docs/books/jls/second_edition/html/memory.doc.html

http://java.sun.com/docs/books/vmspec/2nd-edition/html/Threads.doc.html

# BEA JRockit JVM Throws Errors HotSpot Does Not Throw

Why is BEA JRockit JVM throwing `IllegalAccessError`, `ClassFormatError`, `IncompatibleClassChangeError` or other `LinkageError` exceptions when the Sun JVM is not?

Verification ensures that the binary representation of a class or interface is structurally correct. For example, it checks that every instruction has a valid operation code; that every branch instruction branches to the start of some other instruction, rather than into the middle of an instruction; that every method is provided with a structurally correct signature; and that every instruction obeys the type discipline of the Java programming language.

If an error occurs during verification, then an instance of the following subclass of class `LinkageError` will be thrown at the point in the program that caused the class to be verified

Example: Using JTidy throws IllegalAccessError

In an early version of JTidy from Apache Software Foundation, the compiler had incorrectly inlined a reference to a private variable belonging to an outer class. This caused an exception to be thrown since BEA JRockit JVM does stricter verification than the Sun JVM is. The old `Tidy.jar` should be replaced with the new and correctly compiled version.

# Slow Performance in Development Mode

Why is BEA JRockit JVM slower when BEA WebLogic Server is running in development mode?

When WebLogic Server is started in development mode, BEA JRockit JVM is by default started with the `-Xdebug` option. This makes BEA JRockit JVM run with some overhead.

Note: This option is purely for diagnostics use and should therefore not be used in a production type environment.

# BEA JRockit JVM Does Not Run Jakarta Tomcat as a Windows Service

I cannot get BEA JRockit JVM to run Jakarta Tomcat as a Windows service. What am I doing wrong?

The quick answer to this problem is: if you are using `jk_nt_service`, do everything that you need to do for the Sun JVM, then exchange the non-standard Sun JVM `-Xrs` startup option with the non-standard BEA JRockit JVM `-Xnohup` in the `wrapper.properties` configuration file. The rest of this answer is a slightly more detailed description of this.

1. First make sure that you have completed all the tasks concerning the environment variables in "I cannot get my favorite Java application to run on BEA JRockit JVM. What am I doing wrong?" above.

Many people use the `jk_nt_service` windows service wrapper to run java applications; for example, Jakarta Tomcat, as a Windows service (see http://members.ozemail.com.au/~lampante/howto/tomcat/iisnt/). Independently of what Windows service you may be using you must make sure that it is not using any non-standard startup options. When using `jk_nt_service`, the startup is defined in:

`<tomcat install dir>\conf\jk\wrapper.properties`

2. Make sure that you set the three properties `wrapper.tomcat_home`, `wrapper.java_home` and `wrapper.cmd_line` are set accordingly:

- `wrapper.tomcat_home` must be set with the installation directory of tomcat
- `wrapper.java_home` must be set to the same value as the `JAVA_HOME` environment variable.
- The property `wrapper.cmd_line` defines the startup command. At the time of writing, this property should be set to:

>     wrapper.cmd_line=$(wrapper.javabin) -Xnohup -Djava.security.policy=="$(wrapper.tomcat_policy)" -Dtomcat.home="$(wrapper.tomcat_home)" -classpath $(wrapper.class_path) $(wrapper.startup_

for BEA JRockit JVM. Normally this command includes a non-standard option to stop the JVM from shutting down the process when a user logs off. For BEA JRockit JVM this non-standard option is `-Xnohup`, for the Sun JVM it is `-Xrs`.

# Other Frequently Asked Questions

What is a Java virtual machine?

As described by the Java Virtual Machine Specification:

"The Java virtual machine is the cornerstone of the Java and Java 2 platforms. It is the component of the technology responsible for its hardware- and operating system- independence, the small size of its compiled code, and its ability to protect users from malicious programs."

What is the difference between the Sun JVM and BEA JRockit JVM?

The most well know JVM is the implementation from Sun. The Sun JVM is called HotSpot. The Sun JVM is shipped in the Java Developer's Kit (JDK) and Java Runtime Environment (JRE) from Sun.

The BEA JRockit JVM from BEA systems is optimized for reliability and performance for server side applications. To achieve this, BEA JRockit JVM uses technologies such as code generation, hot spot detection, code optimization, advanced garbage collection algorithms and tight operating system integration.

Should I write my applications differently for BEA JRockit JVM?

No! You should not write your applications in any other way for BEA JRockit JVM than you should for any other JVM. You should, however, design and implement your applications well in order for them to run well on BEA JRockit JVM.