Source code analysis: Memory Allocation of Java objects (1)

Source code analysis: Memory Allocation of Java objects (1)

Java objects are allocated in two ways: Fast allocation and slow allocation. The lock-free pointer collision technology is used to distribute the objects in the new generation Eden zone, the slow distribution has different invocation Layers Based on the implementation methods of the heap, GC, and generation.
The following describes the memory allocation process of the Instance Object Based on the bytecodeInterpreter interpreter's explanation of the new instruction:

1. Quick allocation

1. before creating an instance, you must first know whether the type is loaded and correctly parsed. Based on the CONSTANT_Class_info constant pool index specified by the bytecode, you can obtain the object type information and call is_unresovled_klass () verify whether the class has been parsed. Before creating an instance of the class, make sure that the type has been correctly loaded and parsed.

 
 

  
  
CASE(_new): { 
  
  
        u2 index = Bytes::get_Java_u2(pc+1); 
  
  
        constantPoolOop constants = istate->method()->constants(); 
  
  
        if (!constants->tag_at(index).is_unresolved_klass()) { 
 
 

2. Obtain the instanceKlass representation of this type in the Virtual Machine (For details, refer to the previous example to explore the Java object organization structure)

 
 

  
  
oop entry = constants->slot_at(index).get_oop(); 
  
  
          assert(entry->is_klass(), "Should be resolved klass"); 
  
  
          klassOop k_entry = (klassOop) entry; 
  
  
          assert(k_entry->klass_part()->oop_is_instance(), "Should be instanceKlass"); 
  
  
          instanceKlass* ik = (instanceKlass*) k_entry->klass_part(); 
 
 

3. when the type has been initialized and can be quickly allocated, the UseTLAB determines whether to use the TLAB Technology (Thread-Local Allocation Buffers, Thread Local Allocation Cache Technology) to assign the assignment to the thread. TLAB allocates a small block of memory in advance for each thread in the Java heap. When an object creates a request for memory allocation, it allocates the memory on the block, instead of allocating memory in the Eden zone through synchronization control.

 
 

  
  
if ( ik->is_initialized() && ik->can_be_fastpath_allocated() ) { 
  
  
            size_t obj_size = ik->size_helper(); 
  
  
            oop result = NULL; 
  
  
            // If the TLAB isn't pre-zeroed then we'll have to do it 
  
  
            bool need_zero = !ZeroTLAB; 
  
  
            if (UseTLAB) { 
  
  
              result = (oop) THREAD->tlab().allocate(obj_size); 
  
  
            } 
  
  
            if (result == NULL) { 
  
  
              need_zero = true; 
 
 

4. If TLAB is not used or the allocation fails on TLAB, the allocation will be attempted in the Eden area of the heap. Universe: heap () returns the CollectedHeap used by the VM memory system. top_addr () returns the start address Variable _ top address of the idle block in the Eden area, end_addr () it is the end address Variable _ end address of the idle block in the Eden area. Therefore, compare_to is the starting address of the idle block in the Eden area. new_top is the starting address of the new idle block after the idle block is allocated. Here, the CAS operation is used to synchronize idle blocks, that is, observe the expected value of _ top. If it is the same as compare_to, no other threads can operate on this variable, then new_top is assigned to _ top to truly become the starting address value of the new idle block. This allocation technology is called bump-the-pointer (pointer collision technology ).

 
 

  
  
retry: 
  
  
              HeapWord* compare_to = *Universe::heap()->top_addr(); 
  
  
              HeapWord* new_top = compare_to + obj_size; 
  
  
              if (new_top <= *Universe::heap()->end_addr()) { 
  
  
                if (Atomic::cmpxchg_ptr(new_top, Universe::heap()->top_addr(), compare_to) != compare_to) { 
  
  
                  goto retry; 
  
  
                } 
  
  
                result = (oop) compare_to; 
  
  
              } 
  
  
            } 
 
 

5. Fill in the 0 option based on whether or not to fill in 0 for the object data zone of the allocated space

 
 

  
  
if (result != NULL) { 
  
  
              // Initialize object (if nonzero size and need) and then the header 
  
  
              if (need_zero ) { 
  
  
                HeapWord* to_zero = (HeapWord*) result + sizeof(oopDesc) / oopSize; 
  
  
                obj_size -= sizeof(oopDesc) / oopSize; 
  
  
                if (obj_size > 0 ) { 
  
  
                  memset(to_zero, 0, obj_size * HeapWordSize); 
  
  
                } 
  
  
              } 
 
 

6. Set the object header information based on whether to use the biased lock, and then set the klassOop reference of the object (so that the object itself obtains the way to obtain the type of data)

 
 

  
  
if (UseBiasedLocking) { 
  
  
                result->set_mark(ik->prototype_header()); 
  
  
              } else { 
  
  
                result->set_mark(markOopDesc::prototype()); 
  
  
              } 
  
  
              result->set_klass_gap(0); 
  
  
              result->set_klass(k_entry); 
 
 

7. Introduce the object address to the stack and continue executing the next bytecode

 
 

  
  
SET_STACK_OBJECT(result, 0); 
  
  
              UPDATE_PC_AND_TOS_AND_CONTINUE(3, 1); 
 
 

8. If this type is not parsed, The _ new function of InterpreterRuntime will be called to complete the slow allocation.

 
 

  
  
// Slow case allocation 
  
  
        CALL_VM(InterpreterRuntime::_new(THREAD, METHOD->constants(), index), 
  
  
                handle_exception); 
  
  
        SET_STACK_OBJECT(THREAD->vm_result(), 0); 
  
  
        THREAD->set_vm_result(NULL); 
  
  
        UPDATE_PC_AND_TOS_AND_CONTINUE(3, 1); 
 
 

The above is the process of fast allocation. The flowchart is as follows. The key lies in the lock-free pointer collision technology used for fast allocation in the Eden area.