Hacker News Reader

Comment by antoaravinth | Hacker News Reader

I didn't get them fully. Sorry for novice questions, but wish to understand your statement completely.

>Suppose you are eg storing small integer counts in ints; if it's a java int you are using 4B to store 1B, while if it's a java.lang.Integer it costs 16 bytes plus most likely an 8B pointer.

This wastage does happens only in reference types? Tomorrow say if value types are been created, then these sort of issue will get resolved?

>Another way to consider this is if you are using 8B pointers, you waste a lot of that as constant zeros

Why of constant zeros? And in the line your saying "-- 1TB is 2^40", your referring 1TB of cache line?

View on HN

> This wastage does happens only in reference types? Tomorrow say if value types are been created, then these sort of issue will get resolved?

That would solve most of the issue, yes.

> Why of constant zeros? And in the line your saying "-- 1TB is 2^40", your referring 1TB of cache line?

He was not referring to cache line or anything like that. He was referring to the fact if you can address just 40 bits, upper 24 bits in a 64-bit pointer are wasted in a pointer. I think on x86 real virtual address size is currently 48 bits, so upper 16 bits are "wasted". This wastage will occur with heaps larger than 32 GB when using compressed pointers JVM option. And of course 4 GB (or 2 GB?) with that JVM option disabled.

Similarly, if you use "bool" type, it still takes a byte in current JVM implementations. So you could say 7 bits are wasted there.

Thanks for the explanation. Looks like Java has more memory problems:

1. If OOP pointer is going to eat up our memory, there we loose / waste some bits of memory. 2. And as you have said even using bool type, is going to say waste by 7 bits!

Since we are dealing more with objects in java world, then I guess, 32 bit VMs will be much faster than 64 bit VMs. Or even 16bit will be more faster, from my understanding.

Still I have a final question over here, all the OOP pointers does goes the CPU caches and registers?

32-bit OOP pointer is just multiplied by 8, because all objects have address divisible by 8. 4 GB * 8 = 32 GB.

Example of generated code from some random web page that happened to be there:

http://cr.openjdk.java.net/~shade/8050147/rsp-minus-8.perfas...

  [0x7f189918ae07:0x7f189918ae54] in org.openjdk.VolatileBarrierBench::testWith

  #           [sp+0x30]  (sp of caller)
  0x00007f189918ade0: mov    0x8(%rsi),%r10d
  0x00007f189918ade4: shl    $0x3,%r10

That "shl $0x3,%r10" multiplies the pointer in register r10 by 8 (2^3). So looks like JVM computes the base pointer to an object to a register (r10 in this case) and uses relative addressing from it.

Here's example of using x86 indirect addressing mode to multiply the pointer by 8:

http://shipilev.net/blog/2014/safe-public-construction/stead...

  0x00007fc7b4971644: mov    0xc(%r12,%r11,8),%r10d  ;*getfield instance

In this case effective address for the load from heap is r12 + r11 * 8. Register r12 probably represents heap base pointer or similar in this case - I'm not sure.

16-bit would be significantly slower, but for entirely other reasons. Also, you could have at most 512 kB heap with 8 byte address alignment...

The issue with 64-bit pointers is that Java (and JVM) is a very pointer happy language, so the cost is significantly more than for pretty much any other language I can think of. Memory usage and more cache misses is the issue.

HotSpot compresses pointers on 64-bit systems to 32 bits by default.

https://wikis.oracle.com/display/HotSpotInternals/Compressed...

Reply on news.ycombinator.com