Name: rmT116609			Date: 04/26/2004


A DESCRIPTION OF THE REQUEST :
The jdk 1.5.0 beta1 hotspot client and server compilers on 32-bit Linux seem to round object sizes up to a multiple of 8 bytes.  When memory is tight, this forces developers to make data structure choices based on artifacts of the compiler implementation instead of on the appropriate higher level considerations, which is not good, and makes things difficult to maintain well.

For example, suppose it is necessary to keep a list of N objects like this:

class SomeObject {
    int x;
    int y;
    int z;
}

The objects could be stored in an array, or a next reference could be added to the object so they could be stored in a linked list (remember, memory is tight so we can't afford the memory overhead of a java.util.LinkedList).  At first glance, and disregarding the fixed overhead for creating an array, it seems either choice would simply require N additional 4-byte references, either as array slots or as next references.  However, since SomeObject contains only 12 bytes of data (plus 8 bytes of overhead) and the size is rounded up to 16 bytes of data, the obect contains wasted space and it is possible to add a next reference to the object which will use this wasted space without increasing the size of the object, so this is the way to go:

class SomeObject {
    int x;
    int y;
    int z;
    SomeObject next;
}

But if SomeObject is later modified to have two or four ints instead of three, then holding the objects in an array instead of linking them together would use much less memory since
each array slot would require only 4 bytes whereas adding a next reference would require 8 additional bytes, 4 of which would be wasted.

This is just one example of how rounding object size to a multiple of 8 bytes forces artificial and difficult to maintain choices onto developers coding for tight memory.  And tight memory
doesn't mean small memory, it could mean there is not much usable free space left in a 3GB heap.

I can think of other examples involving hash table and tree data structures where adding another field to an object can have a deep impact on how the data structures should be organized and/or built in order to minimize memory use by ensuring obects do not contain wasted space.

Since the effort has been put into reducing hotspot's per-object overhead to a mere 8 bytes, it seems counter productive to waste space by rounding object sizes up.  Could you please check into whether it would be possible not to do this?  Rounding to 4 bytes would be ok.

JUSTIFICATION :
It would make it easier for people to write and maintain code designed for tight memory situations.  Minimizing memory use may allow people to reduce the number of servers in a server farm and save money.
(Incident Review ID: 255636) 
======================================================================