What is the memory layout of objects in memory?

The storage structure of a Java object. In the Hotspot virtual machine, objects are stored in memory in three areas: object Header, Instance Data, and align Padding.

Java Object Instance

Hotspt uses the Oop-Klass model. It is a model that describes Java object instances and can be divided into two parts:

OOP (Ordinary Object Pointer) refers to a common Object Pointer that contains MarkWord and Klass Pointers. MarkWord is used to store some state data of the current object runtime. The Klass pointer points to Klass, which tells you what type of object the pointer is pointing to, which class was used to create the object and the reason for this binary object model, Because the designers of the hotspot JVM did not want every object to contain a virtual table, they split the object model into KLass and OOP, where OOP does not contain any virtual functions and Klass contains virtual tables. You can do Method Dispatch

– object head

The HotSpot VIRTUAL machine object header contains two pieces of information:

The first part _mark:markOop is used to store the runtime data of the object itself, such as HashCode, GC generation age, lock status flags, locks held by threads, biased thread IDS, biased time stamps, etc. The length of this data is 32-bit and 64-bit, respectively, on a 32-bit or 64-bit VM (with compression pointer disabled). The data is officially called MarkWord.

_KLass: The other part of the klassOop object header is a pointer of type Klass, that is, a pointer to the object’s class metadata, which the virtual machine uses to determine which class the object is an instance of

If the object is an array object, the object header also contains a bit of data representing the length of the array. The size is 32 bits, 4 bytes

– Object actual data

The instance data portion is the valid information that the object actually stores, as well as the content of various types of fields defined in program code. Both inherited from a parent class and defined in a subclass need to be logged.

Alignment filling

The third alignment padding does not necessarily exist and has no special meaning. It serves only as a placeholder. Since HotSpot VM’s automatic memory management system requires that the object’s starting address be an integer multiple of 8 bytes, in other words, the object’s size must be an integer multiple of 8 bytes. The object header is exactly a multiple (1 or 2) of 8 bytes, so when the object instance data part is not aligned, it needs to be filled by alignment.

The simplicity can be summarized as follows

With these four parts in mind, let’s verify the bottom layer. Use the third-party package JOL = Java Object Layout Java memory Layout to see. You can see the memory layout in a few simple lines:

<dependency> <groupId>org.openjdk.jol</groupId> <artifactId>jol-core</artifactId> <version>0.9</version> </dependency> public class JOLSampleDataModels { private static Object o; public static void main(String[] args) { o = new Object(); System.out.println(ClassLayout.parseInstance(o).toPrintable()); System. The out. Println (" = = = = = = = = = = = = = = = = = = after loading lock = = = = = = = = = = = = = = = = = = "); synchronized (o) { System.out.println(ClassLayout.parseInstance(o).toPrintable()); }}}Copy the code

According to the output results:

The object header contains 12 bytes divided into 3 lines, where the first 2 lines are actually Markword and the third line is the klass pointer. Note that the output changed from 001 to 000 before and after the lock. Markword uses 8 byte (64bit) header to record some information, lock is modified Markword content (64bit) header to record some information. Changed from 001 without lock to 00 lightweight lock.

New Produces an object that takes 16 bytes. The Object header takes up 12 bytes, and since there are no extra variables in Object, instance = 0. Considering that the Object memory size is divisible by 8 bytes, the padding=4, and finally the new Object() memory size is 16 bytes.

expand

What kind of objects will enter the old age? Many scenarios such as the object is too large to enter directly, but here I want to explore why the object from the Young GC will enter the Old section after at most 15 experiences while the Young GC is still alive (the age can be adjusted, the default is 15). Mems uses four bits to represent generational ages in the markword graph above, so the maximum range available is 0-15. Therefore, this is why the age of the new generation should not exceed 15, which can be adjusted by -xx :MaxTenuringThreshold at work, but generally we will not change it.

【原文 address 】 : 原文 jump 【 welcome attention 】 : code non architecture

Focus on system architecture, high availability, high performance, high concurrency technology sharing