This script is not for online documents. It is only used by the QuestAgent Java Applet for CD search indexes.
Skip navigation.

dev2dev Home > dev2dev WebLogic JRockit > WebLogic JRockit 8.1 SDK Documention > Developers FAQ

BEA WebLogic JRockit 8.1 Developers FAQ

This page answers some frequently asked questions developers have about WebLogic JRockit JVM and developing applications for the JVM.

What is a Java virtual machine?

(From 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 JRockit?

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 JRockit JVM from BEA systems is optimized for reliability and performance for server side applications. To achieve this, JRockit 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 JRockit?

No! You don't have to write your applications in any differently for JRockit than you should for any other JVM. You should, however, design and implement you applications well in order for them to run well on JRockit.

Why doesn't my application start with JRockit when it starts with the Sun JVM?

This is often due to Sun JVM specific, non-standard startup options. Applications are often started with script files. Read the script files and make sure that only standard or JRockit non-standard options are used. See Tuning WebLogic JRockit 8.1 JVM.

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

Java programs are compiled into byte code by a Java compiler. Many JVMs, including the Sun JVM, interprets this byte code each time the code is executed. JRockit, 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. JRockit 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.

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

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 JRockit garbage collector systems are described in Choosing Memory Management System in Tuning BEA SDK 8.1. Generally the JRockit GC implementations trade memory usage for speed and minimal program wide halts, i.e. acquiring system wide locks. I have a script/program that use JRockit for certain tasks.

Why is it slower than when I use the Sun JVM?

This may be related to the "Why does it take longer for my applications to start with JRockit?" above. Script or other programs may start many java processes and may therefore experience bad performance compared to the Sun JVM, since JRockit 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.

Why does my application have randomly appearing bugs when running on JRockit 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 Java Virtual machine 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

Why is JRockit throwing a 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.

For example:

Usage of JTidy throws ClassFormatError 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 JRockit it stricter checks than the Sun JVM. The old Tidy.jar should be replaced with the new and correctly compiled version.

Should I use thin threads with BEA WebLogic Server?

We recommend that you don't. Thin threads is an alternative to the traditional 1:1 thread mapping model. It may offer improved scalability and performance if used with an application with many (for example, greater than 100 threads); you may want to try this threading implementation if your application is so characterized. Please note, however, that thin threads is experimental in this release..

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

Many problems with running applications on JRockit is due to erroneous environment variables or non-standard startup options. Start by making sure that you environment variables are set up correctly.

When running applications as Windows services it is crucial that you set these environment variables system wide. To do this:

  1. Open Start>Settings>Control Panel>System and select the Advanced tab.
  2. Click the "Environment Variables…" button.
  3. To set system wide environment variables you must edit in the lower part of this dialog box, called 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 WebLogic JRockit 8.1 SDK for complete documentation of standard and non-standard options.

I can't get JRockit 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 JRockit -Xnohup in the wrapper.properties configuration file. The rest of this answer is a slightly more detailed description of this.

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 JRockit. 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 musty 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 Make sure that you set the three properties wrapper.tomcat_home, wrapper.java_home and wrapper.cmd_line are set accordingly:

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

Does WebLogic JRockit support the /3GB Windows startup option?

This version of WebLogic JRockit does not support the /3GB option. It will be supported in the next release. If you want to use this feature—with the understanding that it is not supported, use the Microsoft Visual Studio tool, editbin.exe, on java.exe to enable it.

Does WebLogic JRockit support Physical Address Extension (PAE) on Windows?

Physical Address Extension provides the possibility to map physical memory into your process virtual memory address space. At any given time, you can still have just 2 GB mapped (3 GB with the /3GB option; see the preceding question for limitations of this option with this version of WebLogic JRockit); that is, you have to re-use a portion of the virtual address space to map different portions of the physical address space. Therefore you cannot simply address more memory with regular pointers. This does not work well with a normal Java heap, which uses 32-bit pointers to reference objects and needs the entire heap in the virtual address space at all times.

PAE works well with applications that can jointly control mapping and memory access. At this point this is not well suited for Java. However a native database driver might use PAE to cache data. You should discuss with the various database vendors how to make this happen (if it is not available already). You might even create a custom cache by rolling your own “DB access layer” on top of a native database API using JNI.

Other ways of using your plentiful physical memory includes using several Java processes (each Windows process can get 2 GB physical memory to use for its private address space).

If you a need a larger Java heap, you need to use a 64-bit implementation of WebLogic JRockit; that is, the IA-64 versions for Windows 2003 or Linux.


 WebLogic Platform 8.1 Online Documentation

WebLogic Platform 8.1 includes: WebLogic Server, WebLogic Workshop, WebLogic Portal, WebLogic Integration, WebLogic JRockit