Browse Prior Art Database

Improved field layout of Java classes

IP.com Disclosure Number: IPCOM000015423D
Original Publication Date: 2002-Jan-01
Included in the Prior Art Database: 2003-Jun-20
Document File: 3 page(s) / 50K

Publishing Venue

IBM

Abstract

A program is disclosed to efficiently lay out fields in a Java* Virtual Machine, particularly on 64-bit systems. Java objects have fields, which can hold data of various sizes. An object can hold fields of the following sizes: Type Minimum size Typical size Typical alignment boolean 1 bit 4 bytes 4 bytes byte 1 byte 4 bytes 4 bytes char or short 2 bytes 4 bytes 4 bytes int 4 bytes 4 bytes 4 bytes

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 3

Improved field layout of Java classes

A program is disclosed to efficiently lay out fields in a Java* Virtual Machine, particularly on 64-bit systems. Java objects have fields, which can hold data of various sizes. An object can hold fields of the following sizes:

Type Minimum size Typical size Typical alignment boolean 1 bit 4 bytes 4 bytes
byte 1 byte 4 bytes 4 bytes char or short 2 bytes 4 bytes 4 bytes
int 4 bytes 4 bytes 4 bytes
long 8 bytes 8 bytes 4 or 8 bytes
float 4 bytes 4 bytes 4 bytes
double 8 bytes 8 bytes 4 or 8 bytes reference natural pointer size 4 or 8 bytes 4 or 8 bytes

On a 32-bit implementation of a Java Virtual Machine (JVM) space for fields is typically allocated in slots, where a slot is wide enough to hold a boolean, byte, char, short, int, or reference, and so is 32 bits in size, and 2 slots are needed for longs and doubles. A naive 64-bit implementation will use the same number of slots, but the slots have to be twice as big, because a reference is 64 bits in size. This can nearly double the size of objects on a 64-bit system, as booleans, bytes, chars, shorts and ints take one slot (64 bits), and longs and doubles take two slots (128 bits).

This invention lays out the fields in a more efficient manner, minimizing the wasted space. In general the fields in an object are laid out in the order specified by the class file. Fields are aligned on natural boundaries for the efficient operation on the target machine. For example int fields will be aligned on a 4-byte boundary. Long or double fields will be aligned on 8-byte boundaries (except on machines where a 4-byte boundary would be just as efficient).

With this invention, if padding is required to maintain alignment then a note is kept of the spare padding space that had to be skipped over to align the next field. If a subsequent field can fit into the padding space then the padding space is used for the field. The precise offset used for a field does not matter as a Java program references a field by name, which is then looked up by the Java Virtual Machine via the constant pool to give the field block, giving information about the field including the offset of the field from the start of the object.

If at the end of laying out an object there is some unused padding space then the field before the padding space is swapped with the last field in the object. This has the effect of moving the padding space to the end of the object. This padding space could then be used by extra fields if a new class is created which extends this class and adds some fields.

1

Page 2 of 3

Certain Java classes may have object layouts which a...