Memory allocation declaring a field

How much memory Java allocates for declaring fields like private char letter; and private int 开发者_JAVA百科size; at the moment of constucting the object containing these fields?

---

This depends on the implementation of the virtual machine. The spec specifies that a char primitive type has a value range of 16 Bit, but it does not specify how a virtual machine has to store an object on the heap.

There's no need for such a detailed spec, because VM's don't have to be able to exchange or serialize raw objects from the heap.

---

To respond to your clarification in a comment: Again, it depends on the implementation, but there a couple of good reasons to allocate the memory for all class attributes once at the time the object is "created". If we decided for lazy allocation, then we'd have to add mechanics to dynamically resize objects on the heap at runtime which is pretty expensive.

If we reserve all space right away at the beginning, then we never have to resize or relocate data on the heap, because the datastructures can never grow or shrink in size.

---

In the Oracle/Sun JVM, each object is allocated on an 8-byte boundary. So adding a field may not increase the amount of memory used. However as a guide here are the sizes of primitives

type           typical size
byte, boolean  1 byte
char, short    2 bytes
int, float     4 bytes
long, double   8 bytes

Whether the JVM is 32-bit or 64-bit makes no differences to the size of a primitive but it does change the default size of a reference.

---

I don't know the specificities of the JVM, but if that can help you the char primitive type uses 16-bit (Unicode character) to store the data, and int uses 32-bits

http://download.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html

I guess you could test it by creating a very simple Java application and a very simple object. Run the application without declaring fields and check how much memory it uses (Ctrl+Shift+Escape in Windows), and then re-run and check the difference when you do allocate these fields.

---

Fields in Java classes that store primitive types are initialised with default values when the object is created, so I would imagine the memory would be allocated then.

---

This is implementation dependent.

Early JVM implementations were closer to the class file format. In that case byte, short, char, int, float and references take up one slot; long and double two slots. So, effectively round size up to four bytes and that's how much memory it takes up in the object. Then the total for the object, including header, is often rounded up to 8 bytes for better memory alignment. For "compressed oops" (32 bit references on 64 bit platforms, where the bottom bits of the 64-bit address are always zero, allowing the reference to be shifted and more than 4 GB used whilst keeping references down to four bytes), there is strong pressure to align to bigger sizes.

But for the best part of a decade we have had 64-bit JVMs. That means more waste, including waste in terms of processor-memory bandwidth. So in modern implementations the object layout is compacted such that object uses as much memory as you would expect (plus header and alignment rounding).