Editing Java virtual machine (section)

===Virtual machine architecture===
The JVM operates on specific types of data as specified in Java Virtual Machine specifications. The data types can be divided<ref>{{Cite web|url=https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-2.html#jvms-2.2|title=Chapter 2. The Structure of the Java Virtual Machine|access-date=2021-09-15|archive-date=2021-09-15|archive-url=https://web.archive.org/web/20210915050448/https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-2.html#jvms-2.2|url-status=live}}</ref> into primitive types ([[integer]]s, Floating-point, long etc.) and Reference types. The earlier JVM were only [[32-bit computing|32-bit]] machines. <code>long</code> and <code>double</code> types, which are [[64-bit computing|64-bits]], are supported natively, but consume two units of storage in a frame's local variables or operand stack, since each unit is 32 bits. <code>boolean</code>, <code>byte</code>, <code>short</code>, and <code>char</code> types are all [[sign-extended]] (except <code>char</code> which is [[Sign extension#zero-extended|zero-extended]]) and operated on as 32-bit integers, the same as <code>int</code> types. The smaller types only have a few type-specific instructions for loading, storing, and type conversion. <code>boolean</code> is operated on as 8-bit <code>byte</code> values, with 0 representing <code>false</code> and 1 representing <code>true</code>. (Although <code>boolean</code> has been treated as a type since ''The Java Virtual Machine Specification, Second Edition'' clarified this issue, in compiled and executed code there is little difference between a <code>boolean</code> and a <code>byte</code> except for [[Name mangling#Java|name mangling]] in [[method signature]]s and the type of boolean arrays. <code>boolean</code>s in method signatures are mangled as <code>Z</code> while <code>byte</code>s are mangled as <code>B</code>. Boolean arrays carry the type <code>boolean[]</code> but use 8 bits per element, and the JVM has no built-in capability to pack booleans into a [[bit array]], so except for the type they perform and behave the same as <code>byte</code> arrays. In all other uses, the <code>boolean</code> type is effectively unknown to the JVM as all instructions to operate on booleans are also used to operate on <code>byte</code>s.) However, newer JVM releases, such as the OpenJDK HotSpot JVM, support 64-bit architecture. Consequently, you can install a 32-bit or 64-bit JVM on a 64-bit operating system. The primary advantage of running Java in a 64-bit environment is the larger address space. This allows for a much larger Java heap size and an increased maximum number of Java Threads, which is needed for certain kinds of large applications; however there is a performance hit in using 64-bit JVM compared to 32-bit JVM.

The JVM has a garbage-collected heap for storing objects and arrays. Code, constants, and other class data are stored in the "method area". The method area is logically part of the heap, but implementations may treat the method area separately from the heap, and for example might not garbage collect it. Each JVM thread also has its own [[call stack]] (called a "Java Virtual Machine stack" for clarity), which stores [[Call stack#STACK-FRAME|frames]]. A new frame is created each time a method is called, and the frame is destroyed when that method exits.

Each frame provides an "operand stack" and an array of "local variables". The operand stack is used for operands to run computations and for receiving the return value of a called method, while local variables serve the same purpose as [[Processor register|registers]] and are also used to pass method arguments. Thus, the JVM is both a [[stack machine]] and a [[register machine]]. In practice, HotSpot eliminates every stack besides the native thread/call stack even when running in Interpreted mode, as its Templating Interpreter technically functions as a compiler.