Memory layout for Java objects

Recently writing a socket communication program for C + + and Java. Need to transfer the bytes received to an object, extending the problem, to find some information on the web, summarized such as the following

This article includes only the memory layout of simple Java objects, regardless of inheritance

An instance of the Java class includes object headers, non-static data members, and alignment data in memory.

static data members, which are shared by all instances of the class. Not saved in an object instance .

The size of the object header depends on the implementation of the JVM. Same JVM, ordinary object, array object. The object header size of the inner object is also different.

The size of the base data type The JVM specification is clearly defined, but the reference type is 4 bytes under the 32bit JVM, and the 64bit JVM is 8 bytes (the pointer compression parameter usecompressedoops is not enabled).

The 32bit JVM and the 64bit JVM are generally 8-byte aligned.

A 64bit JVM inside a basic object memory layout might look like the following

The object header of an array object is 24 bytes, minus 16 bytes of basic information, plus 4 bytes of length data. 4-byte alignment of the data. Other than that. Each element of an array of objects holds a reference to an object.

The object header of a non-static inner object is also 24 bytes. 16 bytes of basic information, plus an external class reference of 8 bytes, 64bit JVM is 8 bytes, 32bit JVM is 4 bytes plus alignment data 4 bytes.

Suppose that the member of the object contains other objects, such as arrays, strings, which simply hold references to these member objects, whose memory is not directly included in the object's memory, outside of it.

Does a non-static member have a consistent position and declaration order in object memory? may not

I found an article about the blog, written in 2008 http://www.importnew.com/1305.html

It mentions Sun VMs, which are now Oracle VMS. ) does not have a memory layout in the order in which they are declared, in order to save memory in the following order

1. Double type (doubles) and long Integer (longs)

2. Integral type (ints) and float type (floats)

3. Short integer type (shorts) and character type (chars)

4. Boolean type (booleans) and byte type (bytes)

5. Reference type (References)

This blog mentions 5 rules.

Rule 1: No matter what object is 8 bytes are aligned to the grain size.

Rule 2: Class attributes are arranged according to such priorities as the following: long and double types. Integer and float type, character and short integer, Byte type and Boolean type, and finally reference type. These properties are aligned according to their respective units.

Rule 3: Members in a non-homogeneous inheritance relationship cannot be mixed. The members in the parent class are processed first in accordance with Rule 2. Next is the member of the subclass.

Rule 4: When the last member of the parent class and the first member of the subclass assume that the interval is not enough for 4 bytes, it must be extended to a base unit of 4 bytes

Rule 5: Assume that the first member of a subclass is a double or long integer. And the parent class does not have 8 bytes to complete. The JVM will break rule 2. According to the shape (int), the short integer. byte type (byte), the order of the reference type (reference), fills the unfilled space.

So the rule is still more complicated.

This blog post was written in 2008. The implementation of the JVM is very likely to have changed, and the JVM version number is very large, it is a little more difficult to understand so many of the individual specifications, from a useful point of view, to just understand the layout of an object

OPENJDK provides a tool. Being able to view the memory layout of an object, this blog describes the tool http://blog.csdn.net/aitangyong/article/details/46416667, which can be analyzed using this tool.

Description

This article was published by Giantpoplar in Csdn

Article Address http://blog.csdn.net/giantpoplar/article/details/47657377

Reproduced please retain this note

Memory layout for Java objects