max heap size for compressed oops

[Matthias Wahl]

Am 12/11/15 um 4:32 PM schrieb Andrew Dinn:
> On 11/12/15 15:13, Matthias Wahl wrote:
>> Thanks for your quick reply.
>>
>> This makes complete sense.
>>
>> It sheds some light on how compressed oops work.
>> Unfortunately it does not answer my initial question.
>   . . .
>> Does anybody have a clue on why heaps > 30.5 GB may induce really worse
>> performance characteristics? Be it G1 or CMS Garbage Collector.
> 
> Evidently it didn't make *complete* sense.
> 
> If you retry your experiment using both a 32 GB and a heap slightly
> smaller than 32GB you will see that Andrew's answer really does address
> your question.
> 
> Here's a 32GB heap:
> 
> [adinn at sputstik ~]$ java -XX:+UnlockDiagnosticVMOptions
> -XX:+PrintCompressedOopsMode -Xmx30g -Xms30g -XX:+UseCompressedOops -version
> 
> Protected page at the reserved heap base: 0x00007fe0b7700000 / 524288 bytes
> 
> heap address: 0x00007fe0b7780000, size: 30802 MB, Compressed Oops with
> base: 0x00007fe0b777f000
> 
> java version "1.7.0_75"
> Java(TM) SE Runtime Environment (build 1.7.0_75-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 24.75-b04, mixed mode)
> 
> So, this heap is not zero based which means compressed oops are stored
> and loaded in other objects as offsets. They need to be converted
> to/from addresses by adding or subtracting the heap base.
> 
> Now, here's a 28GB heap
> 
> [adinn at sputstik ~]$ java -XX:+UnlockDiagnosticVMOptions
> -XX:+PrintCompressedOopsMode -Xmx28g -Xms28g -XX:+UseCompressedOops -version
> 
> heap address: 0x00000000fad80000, size: 28754 MB, zero based Compressed Oops
> 
> java version "1.7.0_75"
> Java(TM) SE Runtime Environment (build 1.7.0_75-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 24.75-b04, mixed mode)
> [adinn at sputstik ~]$
> 
> This smaller heap is zero-based which means compressed oops are absolute
> addresses, rather than offsets. So, they can be stored and loaded
> into/from objects without the need to add or subtract a base address.
> 
> That is enough to make a *big* difference to performance.

Yeah that is true as Andrew Haley already pointed out showing the
assembly which gets produced.

But as the important border for zero based compressed oops is around 28 GB
it cannot be a reason for suggesting 30.5 GB as heap size for
performance reasons. As you've shown above even for 30 GB you already
have compressed oops with a base > 0.

That's why I am now asking for reasons related to the garbage collector
that might cause bad performance especially for heaps > 30.5 GB.


Kind regards

Matthias Wahl