This is the 22nd day of my participation in the August Wen Challenge.More challenges in August

Program counter

  • Thread private

  • The only region where OutOfMemoryError exceptions are not specified

  • It can be thought of as a line number indicator of the bytecode being executed by the current thread

  • If the thread is executing a Java method, this counter records the address of the virtual machine bytecode instruction being executed. If you are executing a Native method, this counter value should be null.

    Let’s imagine, how does the CPU know to remember where thread A went before?

    The answer is that the CPU doesn’t remember where it was; it just keeps its head down; What makes a program that switches threads work? The answer is: program counters; The program counter holds the line number of the bytecode (which looks like the line number, but is actually the instruction address) executed by the current thread.

    So, how many program counters do we need? If we had only one, after switching thread B, the program counter would store the line number of the bytecode executed by thread B, and if we switched back to thread A, we would have no idea where it was executed, because the program counter would store the address of the bytecode currently executed by thread B. Therefore, we can imagine that each thread is assigned a program counter, so that the memory space of the program counter is thread private; This way, even if thread A is suspended, the program counter in thread A will remember the instruction address of the bytecode that thread A is currently executing. When thread A is cut back, it will look at the program counter and know where it was before it was executed.

    So the program counter, when does it allocate memory? Let’s imagine that a thread loses CPU execution rights for any period of time it executes. Therefore, we need to keep track of where the thread is currently executing from the moment it is created. So, thread counters, they have to be created when the thread is created to start executing, they have to be created together;

    The program counter, save the currently executing bytecode offset address (which is the number of rows in the said before, actually that’s not a line number, is the offset address instruction, just for the sake of good understanding,, to say the line number), when the execution to the next instruction, just change the program counter in the save the address, does not need to apply for a new memory to save the new instruction address; Therefore, you can never run out of memory; Therefore, the JVM virtual machine specification does not specify, and is the only area that does not specify, OutOfMemoryError exceptions;

    When a thread executes a local method, the value stored in the program counter is null (undefined). The reason is simple: the native methods are written in C++/C, called by the system, and do not generate bytecode files at all, so the program counter does not record anything

Java virtual machine stack

  • Thread private
  • If the stack depth requested by the thread is greater than the depth allowed by the virtual machine, it is thrownAbnormal StackOverflowError;
  • If the Java virtual machine stack size can be dynamically expanded, it will be thrown when the stack size cannot be allocated enough memoryAn OutOfMemoryError; The HotSpot virtual machine stack size is not dynamically scalable, but the old Classic virtual machine did. – There is no OutOfMemoryError on a HotSpot vm due to the stack being unable to expand – the thread will not get an OOM if it successfully applies for stack space, but will still get an OOM exception if it fails to apply for stack space.
  • -Xss5m: sets the stack capacity of 5m
  • Each method execution creates a stack frame, which contains local variables, operand stacks, dynamic links, method exits, and so on

Local method stack

  • Thread private

  • Similar to the Java virtual machine stack

  • Different from the Java Virtual machine stack: The Java virtual machine stack performs Java methods (that is, bytecode) services for the virtual machine, while the Native method stack serves Native methods used by the virtual machine.

  • Hot-spot virtual machines simply combine the local method stack with the virtual machine stack

  • Like the virtual stack, the local method stack throws StackOverflowError and OutOfMemoryError, respectively, when the stack depth overflows or the stack extension fails

The Java heap

  • Threads share
  • All Java object instances are not necessarily allocated memory on the Java heap
  • Java heaps can be implemented as either fixed size or extensible, but most current Java virtual machines are implemented as extensible (with parameters)-Xmxand-XmsSet).
  • The Java virtual machine will throw an OutOfMemoryError if there is no memory in the Java heap to complete the instance allocation and the heap can no longer be extended.
  • The Java heap is an area of memory managed by the Garbage collector

Methods area

  • Threads share

  • Used to store type information that has been loaded by the virtual machine, constants, static variables, code cache compiled by the just-in-time compiler, and so on.

  • Although the Java Virtual Machine Specification describes the method area as a logical part of the Heap, it has an alias ** “non-heap” to distinguish it from the Java Heap **.

  • Prior to JDK1.6, method sections were implemented using persistent generations.

    • -xx :MaxPermSize Sets the maximum memory size of the permanent generation
    • -xx :PermSize Sets the permanent memory

  • JDK1.7 moves the constant pool of strings, class statics, to the Java Heap, but the persistent generation still exists, mainly for class information (constant pool of operations), etc.

  • Permanent generation is removed completely in JDK1.8, and the method area is replaced by a meta-space implemented in local memory. The information of permanent generation in JDK1.7 is moved to the meta-space, such as the string constant pool and static variables are still stored in the Java Heap

  • OutOfMemoryError is thrown if the method area cannot meet the new memory allocation requirements.