| understanding size for jagged byte[][] [message #3986] |
Tue, 02 September 2008 21:29  |
 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 #4132 is a reply to message #3997] |
Wed, 03 September 2008 17:00  |
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.
|
|
|
Powered by
FUDForum. Page generated in 0.03171 seconds
] 
Search
Help
Register
Login
Home
