Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » Memory Analyzer (MAT) » understanding size for jagged byte[][]
understanding size for jagged byte[][] [message #3986] Tue, 02 September 2008 17:29 Go to next message
Taras Tielkes is currently offline Taras Tielkes
Messages: 38
Registered: July 2009
Member
I'm looking at an application that uses byte[][] instances of various
shapes, sizes and amounts.

To better understand byte[][] memory consumption, I decided to take a
look at the memory reported by MA tool for this dummy byte[][]:
---
byte[][] test = new byte[16][]; -- 80
test[0] = new byte[0]; -- 16
test[1] = new byte[1]; -- 16
test[2] = new byte[5]; -- 24
test[3] = new byte[11]; -- 24
test[4] = new byte[13]; -- 32
test[5] = new byte[24]; -- 40
test[6] = new byte[27]; -- 40
test[7] = new byte[28]; -- 40
test[8] = new byte[29]; -- 48
test[9] = new byte[31]; -- 48
test[10] = new byte[32]; -- 48
test[11] = new byte[33]; -- 48
test[12] = new byte[121]; -- 136
test[13] = new byte[127]; -- 144
test[14] = new byte[128]; -- 144
test[15] = new byte[129]; -- 144

from top: 1072 retained, 80 shallow
---
Heap dump was obtained from a Sun 1.6.0_07 32bit JVM running on WinXP
32bits.

I'm trying to better understand (and estimate) the memory used by
byte[][] (or byte[][][]) instances of various size and shape.

Since the MA developers are doing object graph size calculation before
breakfast (so to speak), I thought I'd ask here from some pointers on
better understanding above numbers.

Below are some fragments of my obviously incorrect/incomplete
understanding of the matter, and questions:
1) shallow size of each object will include (on 32 bits):
a) object tag in memory (4 bytes?)
b) monitor object (4 bytes?)
c) length field? (for arrays) (4 bytes)

2) it seems the size for byte[]s increases in 8-byte steps, but
confusingly not on 8-byte boundaries? (perhaps because first 12 bytes
are used by data described in (1) above, and raw data comes after that?)

3) I'd like to know which parts of the (native) data structures used by
the JVM for above object graph will change size when moving from 32 to
64 bit JVM.

If any of the MA developers would take the time to explain above
reported size, I'd be very grateful.

Any references to specs or (OpenJDK) JVM sources would also be immensely
appreciated.

Kind regards,
(and kudos for a great tool)

-tt
Re: understanding size for jagged byte[][] [message #3997 is a reply to message #3986] Wed, 03 September 2008 03:30 Go to previous messageGo to next message
Krum Tsvetkov is currently offline Krum Tsvetkov
Messages: 149
Registered: July 2009
Senior Member
Hi Taras,

Here is how we currently calculate the sizes. I assume there may be VMs
for which this is not true.

1) size of objects:

1. a) size of java.lang.Object is 2 * id_size (e.g. 8 bytes on 32 bit, 16
bytes on 64)

1. b) size of own fields, plus size of the superclass. Then aligned up to
a multiple of 8. If you have a deeper hierarchy you may "lose" some bytes
by the aligment on each level.

2) arrays of objects: 2 * id (header) + 4 (length) + length * id (content)
- aligned to a multiple of 8

3) primitive arrays: 2 * id (header) + 4 (length) + length * [size of the
type] (content) - aligned to a multiple of 8

In your example test should be calculated as an Object array, and the
element of test as primitive arrays.

> but confusingly not on 8-byte boundaries

I didn't see where it is not aligned to 8?

I hope this explains your first two questions. If not, let me know I'd try
to do it better.

The details should also give you an idea which parts will grow on a 64 bit
system. However, as I said this is the current state, and I assume is VM
specific. On the JavaOne this year I heard in one session that there is
work ongoing (or done) to reduce the overhead on 64 bit systems by using a
bigger storage for object ids only if this is needed. If I misunderstood
or someone can add more details, please do it.

krum
Re: understanding size for jagged byte[][] [message #4132 is a reply to message #3997] Wed, 03 September 2008 13:00 Go to previous message
Taras Tielkes is currently offline Taras Tielkes
Messages: 38
Registered: July 2009
Member
Thanks Krum,

With your explanation my calculations now add up, both for 32bit as well
as 64bit Sun JVM dumps.

Is there some description available on what information the JVM stores
in the object header (8 bytes on 32bit, 16 bytes on 64bit)?

Thanks again for taking the time to explain this,

Taras

Krum Tsvetkov wrote:
> Hi Taras,
>
> Here is how we currently calculate the sizes. I assume there may be VMs
> for which this is not true.
>
> 1) size of objects:
>
> 1. a) size of java.lang.Object is 2 * id_size (e.g. 8 bytes on 32 bit,
> 16 bytes on 64)
>
> 1. b) size of own fields, plus size of the superclass. Then aligned up
> to a multiple of 8. If you have a deeper hierarchy you may "lose" some
> bytes by the aligment on each level.
>
> 2) arrays of objects: 2 * id (header) + 4 (length) + length * id
> (content) - aligned to a multiple of 8
>
> 3) primitive arrays: 2 * id (header) + 4 (length) + length * [size of
> the type] (content) - aligned to a multiple of 8
>
> In your example test should be calculated as an Object array, and the
> element of test as primitive arrays.
>
>> but confusingly not on 8-byte boundaries
>
> I didn't see where it is not aligned to 8?
>
> I hope this explains your first two questions. If not, let me know I'd
> try to do it better.
>
> The details should also give you an idea which parts will grow on a 64
> bit system. However, as I said this is the current state, and I assume
> is VM specific. On the JavaOne this year I heard in one session that
> there is work ongoing (or done) to reduce the overhead on 64 bit systems
> by using a bigger storage for object ids only if this is needed. If I
> misunderstood or someone can add more details, please do it.
Previous Topic:Huge heap dump files - takes hours to parse
Next Topic:Exploring all GC roots in dump
Goto Forum:
  


Current Time: Fri Aug 01 12:14:49 EDT 2014

Powered by FUDForum. Page generated in 0.02252 seconds