Sunday, March 24, 2019

Deciding Heap memory size in Cassandra

32GB or 64GB heap memory to be chosen.

Compressed Oops(Ordinary Object Pointers):

C Language Data Type Models: LP64 AND ILP32

The 32-bit Solaris C language data model, called ILP32, defines int, long, and pointers as 32 bits, short as 16 bits, and char as 8 bits. The C data type model chosen for 64 bit operating system is LP64. This data model defines long and pointers as 64 bits, int as 32 bits, short as 16 bits, and char as 8 bits.

In LP64, only longs and pointers change size; the other C data types stay the same size as in the ILP32 model.

C Type ILP32 LP64
char            8            8
short   16            16
int           32            32
long           32            64
long long           64            64
pointer   32            64

An "oop", or "ordinary object pointer" in Hotspot parlance is a managed pointer to an object.It is normally the same size as a native machine pointer. A managed pointer is carefully tracked by the Java application and GC subsystem, so that storage for unused objects can be reclaimed. This porcess can also involve relocating(copying) objects which are in use, so that storage can be compacted.

On an LP64 system, an oop requires 64 bits, while on ILP32 systems, oops are only 32 bits. But on an ILP32 system there is a maximum heap size of somewhat less than 4Gb, which is not enough for many applications. On an LP54 system, though, the heap for any given run may have to be around 1.5times as large as for the corresponding ILP32 system.

Compressed oops represent managed pointers (in many but not all places in the JVM) as 32-bit values which must be scaled by a factor of 8 and added to a 64 bit base address to find the object they refer to. This allows applications to address up to four billion objects(not bytes), or a heap size of up to about 32Gb.

We use the term decoed to express the operation by which a 32 bit compressed oop is converted into a 64 it native address into the managed heap. The inverse operation is encoding.

Which oops are compressed?
In an ILP32-mode JVM, or if the UseCompressedOops flag is turned off in LP64 mode, all oops are the native machine word size.

If UseCompressedOops is true, the following oops in the heap will be compressed:

1) the klass field of every object
2) every oop instance field
3) every element of an oop array (objArray)

Compressed oops is supported and enabled by default in Java SE 6u23 and later. In java SE 7, use of compressed oops is the default for 64-bit JVM processes when -Xmx isn't specified and for values of -Xmx less that 32 gigabytes.

For JDK 6 before the 6u23 release, use the -XX:+UseCompressedOops flag with the java command to enable the feature.


Heap Size configuring:
If a JVM is started with unequal initial and max heap size, it can be prone to pauses as the JVM heap is resized during system usage. To avoid these resize pauses, it's best to start the JVM with initial heap size equal to maximum heap size.

***
Credits:
https://wiki.openjdk.java.net/display/HotSpot/CompressedOops

https://docs.oracle.com/cd/E19620-01/805-3024/lp64-1/index.html

https://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html

https://www.elastic.co/guide/en/elasticsearch/reference/6.6/heap-size.html

***

No comments:

Post a Comment