大家好，又见面了，我是你们的朋友全栈君。如果您正在找激活码,请点击查看最新教程,关注关注公众号 “全栈程序员社区” 获取激活教程,可能之前旧版本教程已经失效.最新Idea2022.1教程亲测有效,一键激活。

Jetbrains全系列IDE稳定放心使用

Using the dump extractor, jextract

To use the full facilities of the dump viewer, you must first run the jextract tool on the system dump. The jextract tool obtains platform-specific information such as word size, endianness, data structure layouts, and symbolic information. It puts this information into an XML file. You must run the jextract tool on the same platform and the same JVM level (ideally the same machine) that was being used when the dump was produced. The combination of the dump file and the XML file produced by jextract allows the dump viewer (jdmpview) to analyze and display Java™ information.

The extent to which
jextract can analyze the information in a dump is affected by the state of the JVM when it was taken. For example, the dump could have been taken while the JVM was in an inconsistent state. The
exclusive and
prepwalk dump options ensure that the JVM (and the Java heap) is in a safe state before taking a system dump:

-Xdump:system:defaults:request=exclusive+prepwalk

Setting this option adds a significant overhead to taking a system dump; this overhead could cause problems in rare situations. This option is not enabled by default.

jextract is in the directory sdk/jre/bin.

To invoke jextract, at a command prompt type:

jextract <dumpfile> [<outputfile]

On z/OS®, you can copy the dump to an HFS file and supply that as input to
jextract, or you can supply a fully qualified MVS data set name. For example:

> jextract USER1.JVM.TDUMP.SSHD6.D070430.T092211
Loading dump file...
Read memory image from USER1.JVM.TDUMP.SSHD6.D070430.T092211
VM set to 10BA5028
Dumping JExtract file to USER1.JVM.TDUMP.SSHD6.D070430.T092211.xml
<!-- extracting gpf state -->
...
Finished writing JExtract file in 5308ms
Creating zip file: USER1.JVM.TDUMP.SSHD6.D070430.T092211.zip
Adding "USER1.JVM.TDUMP.SSHD6.D070430.T092211" to zip
Adding "USER1.JVM.TDUMP.SSHD6.D070430.T092211.xml" to zip
Adding "/u/build/sdk/jre/lib/J9TraceFormat.dat" to zip
jextract complete.

This produces a compressed (
.zip) file in the current HFS directory.

The jextract tool accepts these parameters:

-nozip

Do not compress the output data.

-help

Provides help information.

By default, output is written to a file called <dumpfile>.zip in the current directory. This file is a compressed file that contains:

The dump
XML produced from the dump, containing details of useful internal JVM information
Other files that can help in diagnosing the dump (such as trace entry definition files)

Typically, you would send the compressed file to IBM® for problem diagnosis. Submitting data with a problem report tells you how to do that.

To analyze the dump locally, extract the compressed file using unzip -d dir <file> or jar xvf <file>. You are also advised to run jdmpview from that new folder.

If you run jextract on a JVM level that is different from the one for which the dump was produced, you will see the following messages:

J9RAS.buildID is incorrect (found e8801ed67d21c6be, expecting eb4173107d21c673). 		
This version of jextract is incompatible with this dump. 		
Failure detected during jextract, see previous message(s).

You can still use the dump viewer on the dump, but it will be limited in the detail that it can show.

The contents of the compressed file produced and the contents of the XML are subject to change, so you are advised not to design tools based on them.

Using the dump viewer, jdmpview

The dump viewer is a cross-platform tool that you use to examine the contents of system dumps produced from the JVM. To be able to analyze platform-specific dumps, the dump viewer can use metadata created by the jextract tool. The dump viewer allows you to view both Java™ and operating system information from the time the dump was produced.

jdmpview is in the directory sdk/bin.

To start jdmpview, at a command prompt type:

jdmpview dumpfile

The jdmpview tool accepts these parameters:

-d
<dumpfile>

Specify a dump file.

-w
<workingdir>

Specify a writable directory.

-o
<outputfile>

Specify an output file.

-i
<inputfile>

Specify an input command file.

Typical usage is jdmpview <dumpfile>. The jdmpview tool opens and verifies the dump file and the associated xml file, dumpfile.xml.

After jdmpview processes the arguments with which it was launched, it displays the message Ready…. When you see this message, you can start calling commands on jdmpview. You can run an unlimited number of jdmpview sessions at the same time.

You can significantly improve the performance of
jdmpview against larger dumps by ensuring that your system has enough memory available to avoid paging. On larger dumps (that is, ones with large numbers of objects on the heap), you might need to start
jdmpview using the
-Xmx option to increase the maximum heap available to
jdmpview:

jdmpview -J-Xmx<n>

To pass command-line arguments to the JVM, you must prefix them with
-J. For more information about using
-Xmx, see
The xml file produced by
jextract on z/OS® is ASCII, so that it is easily portable to other platforms for use in
jdmpview and other tools. On z/OS,
jdmpview expects the file to be ASCII. If you convert the file to EBCDIC and supply the converted file as input to
jdmpview, you see the error messages:

Parsing of xml started for file CHAMBER.JVM.TDUMP.SSHD9.D070824.T094404.xml... be patient 
*** Error Message: Fatal error encountered processing incoming xml.

It might be useful to convert the xml file to EBCDIC for viewing on z/OS, but make sure you keep the ASCII version for use in
jdmpview.

Dump Analyzer overview

The IBM® Monitoring and Diagnostic Tools for Java™ – Dump Analyzer (referred to hereafter as the Dump Analyzer) is intended to perform automated analysis of dump files produced by the IBM Java VM. Starting with the name of the dump to be analyzed the analysis will attempt to localise the problem and if successful will produce a diagnosis of the error together with sufficient information to fix it or suggestions on how to continue the analysis using other tools (e.g. MDD4J to diagnose out of memory situations). If localization fails then the tool will default to producing summary information from the dump intended to aid further diagnosis.

Background

The Java language has come to be predominant in software development, and thus the reliability of the Java Virtual Machine (VM) has become a very important issue. The VM is typically a reliable piece of software, but of course failures do occur during execution for a variety of reasons. A small number of these problems are due to errors in the VM itself; however, in the majority of cases, they are due to errors or misconfigurations in the software stack above the VM (in WebSphere™ Application Server, for instance) or in the application itself.

The software stack for a typical projects has increased in complexity as information technology has matured, which has led to increasing difficulties for developers trying to determination the causes of problems. In such a complex environment, you may be faced with an overwhelming excess of information with which to diagnose the fault. In a production environment there may well be many gigabytes of heap, hundreds of threads, thousands of classloaders, tens of thousands of classes, and a huge number of objects.

The Dump Analyzer is an extensible framework that seeks to solve this problem for the IBM Java SDK’s. It uses analyzers to interrogate a formatted system dump (each analyzer asking the dump a specific question) and links them together with a script to produce a concise report of the analysis. Typical problems analyzed might be the following.

Out of memory
Deadlock detected
VM terminated due to signal (internal or middleware/java application error)
Further investigation is required

The aim is to diagnose the correct category of problem and either provide a complete diagnosis of the problem or give some information designed to aid diagnosis together with a recommended next course of action.