Object size in Heap (Why so big??)

Performance Tuning
#1

Hello!

I have written an application that does calender-stuff and for every day I use a day-object with the folloing member-variables:


  public short state; 
  public char fSymbol; 
  public byte signSymbol; 
  public byte workMod;
  public boolean tipAvail; 
  public boolean remindAvail; 
  public boolean hourTableAvail;
  public boolean toDoAvail; 
  public boolean isEditable;
  public int julianDay;

I theory such an object should need only 15byte + 2 byte Hotspot “per Object” overhead.
In reality one Object needs about 65 bytes which is nearly quad as much as it should need!

Where does all the memory go? I know that the jvm does some aligning, but what does it do here?
Does it put each variable onto the next machine-word-lenght?

This does not really bother me on desktop (except MSJVM which is god damn slow) but on J2ME powered mobiles this is really ugly!
Is there any other way than to put everything in ints and mascerade it?

Thanks in advance, lg Clemens

PS: I am using a P4 under Linux-2.6 so machine-word-lenght is 4 byte.

#2

I guess short, char, byte and boolean all uses 4 bytes each in memory to improve performance.

You can always pack whatever you need into ints and use shift and masking to get what you need. Combining all the booleans would be the first step.

#3

Shouldn’t boolean use 1 byte?

#4

In theory it should, but it seems the JVM is aliagning each variable to the machine-word-lenght which is 4 byte on my machine.

Btw. I made a mistake in my computation: Hotspot does have an 2-machine-words overhead per Object, not 2 bytes.
That would mean 15 + 8 byte but still not 65byte !?

Hmm, strage, I thought masking started to become obsolete with the beginning of java :frowning:

lg Clemens

#5

[quote]Shouldn’t boolean use 1 byte?
[/quote]
All variables in java have - since java 1.0 - taken either 32 or 64 bytes. By design, everything in java is either one or two stack slots (stack uses 32 bit words for everything). Bytecodes either work on the top slot, or the top two, etc.

Of course, that’s just in the bytecode, so it’s always been up to JVM implementors how much that actuall is in native memory once natively runtime-compiled…

#6

32 or 64 bits

#7

ROFL. So thats why c++ prgorammers call me code “bloated”.

#8

I don’t think the layout or padding in objects on the heap (as opposed to variables on the stack) has ever been defined. A JVM is at liberty to do what ever is convenient (subject to keeping at least the minimum number of bits required to represent the type). What a particular JVM does is likely to depend on the processor involved. Packing booleans into bits is unlikely due to problems with synchronization — get it wrong and another boolean value packed into the same byte may change unexpectedly. Using a full 32 bits is attractive as it avoids having to sign extend the value after loading a byte.
Conceivably a JVM could change the layout of an object during execution (probably as part of GC) if it determined that large numbers of a given class were allocated and slowing execution due to memory starvation.

#9

Conceivably… but no one really cares about “conceivably” or “theoretically”.

Just another argument in favour of mapped objects which have a rigidly defined memory layout :slight_smile:

Cas :slight_smile:

#10

wow - 32bit / 4byte - just a lot for 1 boolean isnt it ?!

Sounds like a lot of bloat…

#11

[quote]Sounds like a lot of bloat…
[/quote]
Sounds like you’re not technically aware of why it is so… Google for Memory Alignment

#12

[quote]wow - 32bit / 4byte - just a lot for 1 boolean isnt it ?!

Sounds like a lot of bloat…
[/quote]
An array of boolean will usually use 1 byte for each element. There are serious (concurrency) problems involved in packing any tighter than this.

#13

well, thanks a lot for all the interresting feedback!

Just one question before all others: I read that hotspot-server does reorder variables so that they can be better aligned and this safes memory. Does anybody know what hotspot-server does really do?

Thanks for the tip - I know about Memory Alignment and its use and usefulness.

Byte why is it a problem to put an array of bytes sequentially in RAM whereas member-variables are aligned?
Just to be thought that much space in heap is used by primitives (because Java-Objects consist of primitives and references) I only can imagine how much memory is wasted!

lg Clemens

#14

Wait until CPU architecture changes and memory alignment isn’t a problem.

Until then we will just have to put up with extra padding to align memory.

It’s not that big of a problem, design your program with that in mind.

Try not to store so many variables, try to design your program to use run time variables.

IE:
public float getCost()
{
return sold * price;
}