JAVA SE8 Virtual Machine specification

2.5. Run-time Data areasthe Java Virtual machine defines various run-time data areas that is used during execution of a P Rogram.  Some of these data areas is created on Java Virtual machine start-up and is destroyed only if the Java virtual machine Exits. Other data areas is per thread. Per-thread data areas was created when a thread was created and destroyed when the thread exits.2.5.1. The PC Registerthe Java Virtual machine can support many threads of execution at once (jls§17). Each Java Vsan thread has a own PC (program counter) register. At any point, each Java Vsan thread is executing the code of a single method, namely the current method (§2.6) For that thread.  If that method isn't native, the PC register contains the address of the Java Virtual machine instruction currently being Executed. If the method currently being executed by the thread was native, the value of the Java Virtual machine's PC Register is und efined. The Java Virtual machine ' s PCRegister is wide enough to hold a returnaddress or a native pointer on the specific platform.2.5.2. Java Virtual machine stackseach Java Virtual machine thread have a private Java virtual machine stack, created at the same Time as the thread. A Java Virtual Machine Stack Stores frames (§2.6). A Java Virtual Machine Stack was analogous to the stack of a conventional language such as c:it holds local variables and Partial results, and plays a part in method invocation and return. Because the Java Virtual machine stack was never manipulated directly except to push and pop frames, frames could be heap all ocated. The memory for a Java Vsan stack does not need to be contiguous. In the first Edition of the Java? Virtual machine specification, the Java Vsan Stack was known as the Java stack. This specification permits Java Virtual machine stacks either to being of a fixed size or to dynamically expand and contract As required by the computation. If the Java Virtual machine stacksWas of a fixed size, the size of each Java Vsan stack may be chosen independently when this stack is created.  A Java Virtual Machine Implementation could provide the programmer or the user control over the initial size of Java virtual  Machine stacks, as-well-as, in the case of dynamically expanding or contracting Java Vsan stacks, control over The maximum and minimum sizes. The following exceptional conditions is associated with Java Vsan stacks:if the computation in a thread Requir Es a larger Java Virtual machine stack than are permitted, the Java virtual machine throws a Stackoverflowerror.if Java Vir Tual machine stacks can be dynamically expanded, and expansion are attempted but insufficient memory can be made available To effect the expansion, or if insufficient memory can is made available to create the initial Java Virtual machine stack For a new thread, the Java Vsan throws an outofmemoryerror.2.5.3. Heapthe Java Virtual Machine have a heapThat's shared among all Java Virtual machine threads. The heap is the Run-time data area from which memory for all class instances and arrays are allocated. The heap is created on virtual machine start-up. Heap storage for objects are reclaimed by an automatic storage management system (known as a garbage collector); Objects is never explicitly deallocated. The Java Virtual machine assumes no particular type of automatic storage management system, and the storage Management TEC Hnique May is chosen according to the Implementor ' s system requirements. The heap may is of a fixed size or may is expanded as required by the computation and may be contracted if a larger heap b Ecomes unnecessary. The memory for the heap does isn't need to being contiguous.  A Java Virtual Machine Implementation could provide the programmer or the user control over the initial size of the heap, as well as, if the heap can is dynamically expanded or contracted, control over the maximum and minimum heap size. The following EXceptional condition is associated with the heap:if a computation requires more heap than can be made available by the AUT Omatic Storage Management System, the Java Virtual machine throws an outofmemoryerror.2.5.4. Method areathe Java Virtual machine have a method area, is shared among all Java virtual machine threads. The method area was analogous to the storage area for compiled code of a conventional language or analogous to the "text" s Egment in an operating system process. It stores Per-class structures such as the Run-time constant pool, field and method data, and the code for methods and con Structors, including the special methods (§2.9) used in class and instance initialization and interface initialization. The method area was created on virtual machine start-up.  Although the method area was logically part of the heap, and simple implementations could choose not to either garbage collect or Compact it. This specification does isn't mandate the location of the the method area or the policies Used to manage compiled code.  The method area is the a fixed size or may be expanded as required by the computation and may be contracted if a larger Method area becomes unnecessary. The memory for the method area does isn't need to being contiguous. A Java Virtual machine implementation could provide the programmer or the user control over the initial size a REA, as well as, with the case of a Varying-size method area, control over the maximum and minimum method area size. The following exceptional condition is associated and the method Area:if memory in the method area cannot be made Availab Le to satisfy a allocation request, the Java Virtual machine throws an outofmemoryerror.2.5.5. Run-time Constant Poola run-time Constant Pool is a per-class or per-interface run-time representation of the Constant_poo L table in a class file (§4.4).  It contains several kinds of constants, ranging from numeric literals known at Compile-time to method and field references That's must be resolveD at Run-time. The Run-time constant pool serves a function similar to that's a symbol table for a conventional programming language, AL Though it contains a wider range of data than a typical symbol table. Each run-time constant pool was allocated from the Java Virtual machine's method area (§2.5.4). The Run-time constant pool for a class or interface are constructed when the class or interface are created (§5.3) by the Ja VA Virtual machine.the Following exceptional condition is associated with the construction of the Run-time constant pool F or a class or interface:when creating a class or interface, if the construction of the Run-time constant pool requires mor E memory than can be made available in the method area of the Java virtual machine, the Java virtual machine throws a out Ofmemoryerror.see§5 (Loading, linking, and Initializing) for information about the construction of the Run-time constant pool.2.5.6. Native Method Stacksan Implementation of the Java Virtual machine could use conVentional stacks, colloquially called "C stacks," to support native methods (methods written in a language other than the Java programming language). Native method Stacks may also is used by the implementation of a interpreter for the Java Virtual machine ' s instruction s Et in a language such as C. Java Virtual machine implementations, cannot load native methods and that does not themselve s rely on conventional stacks need not supply native method stacks. If supplied, native method stacks is typically allocated per thread, the thread is created. This specification permits native method stacks either to being of a fixed size or to dynamically expand and contract as Requ Ired by the computation. If The native method stacks is of a fixed size, the size of each native method stack is chosen independently when tha T stack is created. A Java Virtual Machine Implementation could provide the programmer or the user control over the initial size of the native m Ethod stacks, as well as, in the Case of Varying-size native method stacks, control over the maximum and minimum method stack sizes. The following exceptional conditions is associated with native method stacks:if the computation in a thread requires a la Rger native method stack than is permitted, the Java Virtual machine throws a Stackoverflowerror.if native method stacks C An being dynamically expanded and native method stack expansion is attempted it insufficient memory can be made available, O R if insufficient memory can be made available to create the initial native method stack for a new thread, the Java Virtua L Machine throws an outofmemoryerror.

View Oracle's official documentation Additionally, the string constant pool is located: The Run-time Constant Pool, explained in detail:

5.1. The run-time Constant poolthe Java Virtual Machine maintains a per-type Constant pool (§2.5.5), a run-time data struc Ture that serves many of the purposes of the symbol table of a conventional programming language implementation. The Constant_pool table (§4.4) in the binary representation of a class or interface are used to construct the run-time cons Tant pool upon class or interface creation (§5.3). All references in the Run-time constant pool is initially symbolic. The symbolic references in the Run-time constant pool is derived from structures in the binary representation of the Clas S or interface as follows:a symbolic reference to a class or interface are derived from a constant_class_info structure (§4 .4.1) in the binary representation of a class or interface. Such A reference gives the name of the class or interface in the form returned by the Class.getname method, that is:for a Nonarray class or an interface, the name is the binary name (§4.2.1) of the class or interface. For An array class of n dimensions, the name begins with n occurrences of the ASCII "[" character followed by a representatio N of the element type:if the element type is a primitive type, it's represented by the corresponding field descriptor (§4 .3.2). Otherwise, if the element type is a reference type, it's represented by the ASCII ' L ' character followed by the binary NA Me (§4.2.1) of the element type followed by the ASCII ";" character. Whenever this chapter refers to the name of a class or interface, it should is understood to is in the form returned by th E Class.getname method. A symbolic reference to a field of a class or an interface be derived from a constant_fieldref_info structure (§4.4.2) in The binary representation of a class or interface. Such A reference gives the name and descriptor of the field, as well as a symbolic reference to the class or interface in which the field is to be found. A symbolic reference to a method of a class was derived from a constant_methodref_info strUcture (§4.4.2) in the binary representation of a class or interface. Such A reference gives the name and descriptor of the method, as well as a symbolic reference to the class in which the Me Thod is to be found. A symbolic reference to a method of a interface are derived from a constant_interfacemethodref_info structure (§4.4.2) in The binary representation of a class or interface. Such A reference gives the name and descriptor of the interface method, as well as a symbolic reference to the interface I N which the method is to be found. A symbolic reference to a method handle are derived from a constant_methodhandle_info structure (§4.4.8) in the binary repr Esentation of a class or interface. A symbolic reference to a method type was derived from a constant_methodtype_info structure (§4.4.9) in the binary Represen Tation of a class or interface. A symbolic reference to a call site specifier was derived from a constant_invokedynamic_info structure (§4.4.10) in the bin ARY representation of a CLASS or interface. Such A reference gives:a symbolic reference to a method handle, which would serve as a bootstrap method for an Invokedynami C instruction (§invokedynamic); a sequence of symbolic references (to classes, method types, and method handles), string Li Terals, and run-time constant values which would serve as static arguments to a bootstrap Method;a method name and Method D Escriptor. In addition, certain run-time values which is not symbolic references is derived from items found in the Constant_pool t Able:a string literal is A reference to an instance of class string, and are derived from a constant_string_info structure (§4.4.3) in the binary representation of a class or interface. The CONSTANT_STRING_INFO structure gives the sequence of Unicode code points constituting the String literal.  The Java programming language requires that identical string literals (that's, literals that contain the same sequence of Code points) must refer to the same instance of class String (jls§3.10.5). In addition, if the method String.intern was called on any String, the result is a reference to the same class instance tha T would be returned if the string appeared as a literal.  Thus, the following expression must has the value true: ("a" + "B" + "C"). Intern () = = "abc" to derive a string literal, The Java Virtual Machine examines the sequence of code points given by the constant_string_info structure. If the method String.intern have previously been called on an instance of class String containing a sequence of Unicode cod E points identical to this given by the CONSTANT_STRING_INFO structure and then the result of String literal derivation is a Reference to this same instance of Class String.otherwise, a new instance of class String is created containing the Sequen Ce of Unicode code points given by the CONSTANT_STRING_INFO structure; A reference to this class instance is the result of the string literal derivation. Finally, the Intern method of the new String instance is invoked. RuN-TIME constant values is derived from Constant_integer_info, Constant_float_info, Constant_long_info, or Constant_ Double_info structures (§4.4.4,§4.4.5) in the binary representation of a class or interface. Note that constant_float_info structures represent values in IEEE 754 single format and constant_double_info structures re Present values in IEEE 754 double format (§4.4.4,§4.4.5). The run-time constant values derived from these structures must thus being values that can be represented using IEEE 754 sing Le and double formats, respectively. The remaining structures in the Constant_pool table of the binary representation of a class or interface-the Constant_na Meandtype_info and Constant_utf8_info Structures (§4.4.6,§4.4.7)-is only used indirectly when deriving symbolic refere  NCEs to classes, interfaces, methods, fields, method types, and method handles, and when deriving string literals and call Site specifiers.

The Run-time Constant Pool

JAVA SE8 Virtual Machine specification