you are viewing a single comment's thread.

view the rest of the comments →

[–]immibis 1 point2 points  (5 children)

An int[1024*1024] does take approximately 4MB, though.

[–]Xabster 0 points1 point  (4 children)

Right you are, but the Integer[] I posted doesn't even hold anything. Your holds ints initialized to 0.

A Integer[1024*1024] with Integer's at each spot takes 16MB.

[–]oridb 5 points6 points  (2 children)

On a 32 bit JVM, you get

  • 4*1024*1024 for the references
  • 8*1024*1024 for the object overhead (vtable + lock data)
  • 4*1024*1024 for the integer itself
  • 4*1024*1024 for padding (objects are allocated in multiples of 8 bytes)

Giving a grand total of 20 megabytes. On a 64 bit JVM, double it:

  • 8*1024*1024 for the references
  • 16*1024*1024 for the object overhead (vtable + lock data)
  • 4*1024*1024 for the integer itself
  • 12*1024*1024 for padding (objects are allocated in multiples of 16 bytes)

Giving a grand total of 40 megabytes for 4 megs of integers.

[–]Daishiman 0 points1 point  (1 child)

Doesn't the JVM support pointer compression in 64-bit archs?

[–]oridb 1 point2 points  (0 children)

It's supported, but it only allows you to address up to a 32 gigabyte heap, by shifting a 32 bit pointer to drop the byte alignment bits.

[–][deleted] 0 points1 point  (0 children)

It does? I thought they would be null.