|
|
This chapter serves as a roadmap to how you should approach problems with the Oracle JRockit JVM. At its most basic, this roadmap is comprised of four steps you should follow to arrive at the best solution to your problem. The roadmap is comprised of these step:
Often, if you encounter a problem running an application on the JRockit JVM, the cause is something extremely basic that you might be able to correct with only a small effort. Before diagnosing issues with the JVM, go through the checklist in Table 25-1 to make sure that you have ruled out the most common causes for JVM problems.
| Note: | The list is not in any particular order, which means that each item can be checked separately. |
Sometimes an installation can have gone wrong, that is why you should try to reinstall the JRockit JVM and then try to reproduce the problem. You find the relevant installation instructions in
Installing Oracle JRockit Mission Control
.
|
|||
Knowing that this defect occurs every time the described steps are taken, is one of the most helpful things you can know about it and tends to indicate a straightforward programming error. If, however, it occurs at alternate times, or at one time in ten or a hundred, thread interaction and timing problems in general would be much more likely.
|
|||
A problem that is not evident on another machine could help you find the cause. A difference in hardware could make the problem disappear; for example, the number of processors. Also, differences in the operating system and application software installed might make a difference to the JRockit JVM. For example, the visibility of a race condition in the JVM or a user Java application might be influenced by the speed at which certain operations are performed by the JVM.
|
|||
Code garbage collection can be disabled, while Java heap garbage collection cannot. Although disabling the code garbage collector forces the JRockit JVM to use more memory, if the problem exists in code garbage collection, the JVM should perform normally when it is disabled. To disable code garbage collection, use the command-line option
-XXnoCodeGC at startup.
|
|||
If you are running JNI code from a third party vendor, make sure you have the latest version of that code installed. Look in the text dump, which you can create by using
jrcmd (please refer to
Using jrcmd for more information) to see the list of libraries (DLLs) that are loaded. From that list you can derive which updates you might need.
|
|||
Code optimization is a default process by which commonly-executed code is recompiled to make it run more efficiently. The first time the JRockit JVM runs a method, the method is compiled into machine code. This compilation is quick, but the resulting code isn't as efficient as it could be. While this code is acceptable for methods that are run once and discarded; however, if a method is used repeatedly, the system can get a performance boost if the code for that particular method is regenerated in a more efficient way. The JRockit JVM re-compiles—or “optimizes”—these methods to make the code as efficient as possible. While optimization makes code more efficient, the optimizing compilation takes longer. If the optimizer itself has bugs,
-XnoOpt will help you identify problems related to those bugs.
|
|||
The information that is available in the crash dump files are of interest to the Oracle Support organization. If you have a Oracle Support Agreement, you can provide your support agency with crash dump files to better find what problems there might be.
Crash dump files can be very helpful to Oracle Support. Depending on the platform, crash dump files might not be enabled by default. For more information on crash dumps, please refer to Understanding Crash Files.
|
If none of these causes corrects your problem, proceed to Step 2. Observe the Symptoms.
In most cases, when you encounter a problem, you will only see what’s happening with your application. You won’t know the underlying cause of the problem or where the problem is originating. Therefore, you need to be able to identify the symptom of the problem, rather than its root causes, before you can actually begin resolving it. Table 25-2 provides a list of the most common problem symptoms that users tend to encounter when running into issues with the JRockit JVM. Adjacent to the symptoms will be links to chapters in this section that describe the most likely reason for the problem and provide detailed information on how to handle it.
Once you have identified the symptom, you can usually identify the problem by following the procedures outlined in the relevant sections of the linked chapter. For example, your symptom might be that the JVM starts up unacceptably slow. By following the instructions outlined in the chapter linked to that symptom, you will be able to determine if your problem is with optimization or is for some other reason. Knowing the origin (and, where possible, location) of the problem will be critical to successfully resolving it.
Table 25-2 list common symptoms associated with JVM problems and where, in this guide you can find information pertaining to that symptom.
Depending upon the type of problem you are encountering, you might be able to resolve it yourself. The chapter linked to the symptom (Table 25-2) will provide the steps you need to follow to effect that resolution. If the problem requires escalation to Oracle Support, the chapter linked to the symptom will describe the sort of information you will need to provide when you open a case with them.
If you are a licensed JRockit JVM user and you can’t resolve the problem on your own, you can send a Trouble Reports to the Oracle Support organization (see Submitting Problems to Oracle Support).
|