Java Hotspot Download
Tertulio Searcy
The JVM is by definition a virtual machine, i.e. a software machine that simulates what a real machine does. Like a real machine, it has an instruction set, a virtual computer architecture and an execution model. It is capable of running code written with this virtual instruction set, pretty much like a real machine can run machine code.
HotSpot is an implementation of the JVM concept. It was originally developed by Sun, and now it is owned by Oracle. There are other implementations of the JVM specification, like JRockit, IBM J9, among many others.
A Java Virtual Machine (JVM) is an imaginary computer that has never been physically built as hardware. A JVM runs programs compiled to its imaginary instruction set written to storage as an intermediate representation known as bytecode.
At runtime, the bytecode must be translated from the imaginary instruction set to the actual instruction set of the CPU of the host machine. This can be done on-the-fly by an interpreter. Or the bytecode can be fully compiled and cached, to run faster than through the interpreter, in a process known as Just-In-Time (JIT) compiling.
HotSpot is one implementation of JIT technology that starts by running interpreted, and watches the actual performance of the app. Parts of the app are then selected to be fully-compiled as native code and cached, for much faster execution. HotSpot was developed at Sun as a commercial product. After acquiring Sun, Oracle further evolved HotSpot by combining important parts of their competing product, JRockit. HotSpot is now open-sourced through the OpenJDK project, available free-of-charge.
Another such implementation in OpenJ9, developed by IBM, and now open-sourced through the Eclipse Foundation and available free-of-charge. Some JVM distributions built on OpenJDK replace HotSpot with OpenJ9 while still using the rest of OpenJDK such as the Java SE class libraries. For example, the pre-built distributions available at AdoptOpenJDK provide your choice of HotSpot or OpenJ9 on some hardware.
OpenJ9 is generally known for much faster starting and much lower memory usage initially, while HotSpot may run more efficiently overall for long-running apps. Both are well-regarded, well-worn, and available with distributions of OpenJDK.
The source code for HotSpot is housed, maintained, and further developed as part of the OpenJDK project. The alternative, OpenJ9, is housed, maintained, and further developed at the Eclipse Foundation, while replacing HotSpot in some distributions of OpenJDK.
OpenJDK (Open Java Development Kit) is a free and open source implementation of the Java Platform, Standard Edition (Java SE).The openjdk is a project started by Sun Microsystems, nowadays care by many companies and the community for build a Java Development Kit absolutely in open source. As per the official documentation.
OpenJDK is an open-source implementation of the Java Platform, Standard Edition (Java SE) specifications. In May 2007, Sun released a fully buildable Java Development Kit (JDK) version for Java SE to the OpenJDK Community as free software under the GNU General Public License version two (GPLv2). Sun announced the Interim Governing Board for the OpenJDK community. Sun also announced that OpenJDK-based implementations can use the Java SE 6 Technical Compatibility Kit (JCK) to establish compatibility with the Java SE 6 specification.
The OpenJDK project consists of a number of components - HotSpot (the virtual machine), the Java Class Library and the javac Java compiler.For more on it, visit its site.
The current JVM provided by Sun/Oracle is called HotSpot because it seeks hot spots of use in the code (places where code is more intensively used) for "just-in-time" optimization. From the wikipedia, HotSpot, released as the "Java HotSpot Performance Engine" is a Java virtual machine for desktops and servers, maintained and distributed by Oracle Corporation.
HotSpot is, as mentioned above, a cross-platform implementation of the Java Virtual Machine (JVM) Concept, and is distributed with the OpenJDK (Java Developer Kit), under the GNU General Public License. HotSpot is written mainly in C++, and was originally developed under Sun Microsystems. It is currently developed under the OpenJDK Project, at www.java.net. The HotSpot JVM was available as an add-on for Java 1.2, and later was used as the default Sun JVM in Java 1.3. The JVM is currently in Version 7, Build b147, and has an active development community behind it.
Guys when the JVM Crashes it writes an Error Log hs_err_pid.log. I want to find out what caused the JVM to crash ? How to understand these Logs, is it documented anywhere on how this Log is arranged. I tried to search on the Net but to no avail :-(
Unless you are calling native code (JNI), nothing in your code should ever make JVM crash; so the stack trace information in that log file is probably not meant to be very useful to most developers. That's probably why it might not be documented (at least externally).So the best thing is probably to file a bug report as suggested by the error message.
If the hotspot is occurring in your native code (i.e. the DLL is one of yours), then find out how to persuade your compiler to produce a list of mappings from DLL offset to line number. Obviously, that may mean you need to re-run with the newly compiled DLL and wait for the problem to occur again.
Otherwise, see if searching for that specific line brings up something in Google, bearing in mind that the same error could mean a whole host of things. And see if the DLL name looks like it's something recognisable, e.g. a printer driver name, graphics driver, or some other component that you can track down to a particular call. Whatever that component is, you may be able to upgrade it to a fixed version, or avoid making the call in question. If you're not sure what the component is, it may just be "the JVM" that you need to upgrade-- upgrading at least to the latest update/minor version nubmer of whatever version you're on is probably a good idea.
In the past I've also seen bugs in the JIT compiler that can be temporarily solved by telling it not to attempt to compile the particular method in question-- as I recall vaguely, in these cases, the hotspot error gives some clue as to which method it was (possibly just the dump of the Java stack), but I don't have an example to hand to recall the details.
Command-line options that are prefixed with -XX are specific to the Java HotSpot Virtual Machine. Many of these options are important for performance tuning and diagnostic purposes, and are therefore described in this appendix. For information on all possible -XX options, see the Java HotSpot VM Options.
For a complete list of these flags, use the MBeans tab of the JConsole utility. See the list of values for the DiagnosticOptions attribute of the HotSpotDiagnostic MBean, which is in the com.sun.management domain. The following are the flags:
This option tells the Java HotSpot VM to generate a heap dump when an allocation from the Java heap or the permanent generation cannot be satisfied. There is no overhead in running with this option, so it can be useful for production systems where the OutOfMemoryError exception takes a long time to surface.
The heap dump is in HPROF binary format, and so it can be analyzed using any tools that can import this format. For example, the jhat tool can be used to do rudimentary analysis of the dump. For more information on the jhat tool, see The jhat Utility.
The ConsumeHeap fills up the Java heap and runs out of memory. When the java.lang.OutOfMemoryError exception is thrown, a heap dump file is created. In this case the file is 507 MB and is created with the name java_pid2262.hprof in the current directory.
By default the heap dump is created in a file called java_pidpid.hprof in the working directory of the VM, as in the example above. You can specify an alternative file name or directory with the -XX:HeapDumpPath= option. For example -XX:HeapDumpPath=/disk2/dumps will cause the heap dump to be generated in the /disk2/dumps directory.
When a fatal error occurs, the Java HotSpot VM can optionally execute a user-supplied script or command. The script or command is specified using the -XX:OnError=string command-line option, where string is a single command, or a list of commands separated by semicolons. Within this string, all occurrences of %p are replaced with the current PID, and all occurrences of %% are replaced by a single %. The following examples demonstrate how this option can be used when launching a Java application named MyApp with the java launcher.
On Oracle Solaris operating system the pmap command displays information about the address space of a process. In the example above, if a fatal error occurs, the pmap command is executed to display the address space of the current process.
On Oracle Solaris operating system the gcore command creates a core image of the specified process, and the dbx command launches the debugger. In the example above, the gcore command is executed to create the core image of the current process, and the debugger is started to attach to the process when an unexpected error is encountered.
On Windows the userdump.exe utility creates a crash dump of the specified process. The utility does not ship with Windows and should be downloaded from the Microsoft website as a part of the Microsoft OEM Support Tools package.
When this option is set and a fatal error is encountered, the HotSpot VM will display information about the fatal error and prompt the user to specify whether the native debugger is to be launched. In the case of Oracle Solaris and Linux operating systems, the output and prompt are sent to the application console (standard input and standard output). In the case of Windows, a Windows message box pops up.
In this case a SIGSEGV error has occurred and the user is prompted to specify whether the gdb debugger is to be launched to attach to the process. If the user enters y or yes, gdb will be launched (assuming it is set in the PATH variable).
c80f0f1006