![]() For example, imagine you declared the following class:Ĭlass M圜lass This scheme allows for a good optimization of memory usage. Instead, the attributes are organized in memory in the following order: In order to save some memory, the Sun VM doesn't lay out object's attributes in the same order they are declared. There is a performance reason to do it this way: usually the cost to read a 4 bytes word from memory into a 4 bytes register of the processor is much cheaper if the word is aligned to a 4 bytes granularity. For instance, ints are aligned to a 4 byte granularity, and longs are aligned to an 8 byte granularity. Attributes are always aligned in memory to their size. Memory layout of classes that extend ObjectĪfter the 8 bytes of header, the class attributes follow. Now we know that if we call new Object(), we will be using 8 bytes of the heap for the two header words and nothing else, since the Object class doesn't have any fields. ![]() Rule 1: every object is aligned to an 8 bytes granularity. This is the first rule or objects memory layout: Also, any object is aligned to an 8 bytes granularity. The first word contains the object's identity hash code plus some flags like lock state and age, and the second word contains a reference to the object's class. In the Sun JVM, every object (except arrays) has a 2 words header. Memory layout of classes that have no instance attributes I will lay down a few 'rules that will help explain how the JVM organizes the objects' layout in memory. The remainder of the discussion will focus on the 32 bit Sun JVM. Most of the world, including myself, uses the Sun HotSpot virtual machine though, which simplifies things a lot. The consequence is that you can write a class, and instances of that class in one VM can occupy a different amount of memory than instances of that same class when run in another VM. One complication is that runtime in memory structure of Java objects is not enforced by the virtual machine specification, which means that virtual machine providers can implement them as they please. Most of the times you will be interested on knowing the deep size of an object, but, in order to know that, you need to know how to calculate the shallow size first, which is what I'm going to talk about here. The deep size, on the other hand, takes into account the shallow size of the object, plus the deep size of each object referenced by this object, recursively. The shallow size of an object is the space occupied by the object alone, not taking into account size of other objects that it references. The first distinction to be made is between shallow size and deep size. The answer, it turns out, is not so simple. And both pointer arithmetic and bulk memory copy don't apply because Java doesn't have pointers.īut every Java developer at some point wondered how much memory is used by a Java object. Java has its own IO infrastructure built around serialization. Size of primitive types in Java is defined in the language specification, whereas in C and C++ it depends on the platform. Java doesn't have a corresponding operator. This operator in C and C++ is useful for pointer arithmetic, copying memory around, and IO, for example. C++ features the sizeof operator, that lets you query the size of primitive types and also the size of objects of a given class. ![]() One thing about Java that has always bothered me, given my C/C++ roots, is the lack of a way to figure out how much memory is used by an object. Update (December 18th, 2008): I've postedhere an experimental library that implements Sizeof for Java. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |