3 ms·

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

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?

vardump 12y ago
> 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.
- antoaravinth 12y ago
  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?
  - vardump 12y ago
    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.perfasm 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/steady.perfasm 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.
    - pron 12y ago
      HotSpot compresses pointers on 64-bit systems to 32 bits by default. https://wikis.oracle.com/display/HotSpotInternals/CompressedOops https://wikis.oracle.com/display/HotSpotInternals/Compressed...
  - deleted 12y ago
    [deleted]

vardump 12y ago

> 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.

antoaravinth 12y ago
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?
- vardump 12y ago
  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.perfasm 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/steady.perfasm 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.
  - pron 12y ago
    HotSpot compresses pointers on 64-bit systems to 32 bits by default. https://wikis.oracle.com/display/HotSpotInternals/CompressedOops https://wikis.oracle.com/display/HotSpotInternals/Compressed...
- deleted 12y ago
  [deleted]