Most Popular Posts

27/08/2013

Garbage Collectors - IBM JVM

TL;DR

-Xgcpolicy:gencon (default in V8)-Xgcpolicy:optthruput (previously default)
-Xgcpolicy:optavgpause
-Xgcpolicy:balanced




Details:

Garbage collector in IBM JVM, just as other GCs collects unused, dead, objects from the heap in order to recover some memory so it is able to allocate new objects on the heap. IBM JVM provides several GC algorithms:
  • -Xgcpolicy:gencon
    • Unused objects are removed, and the survivors are allocated in survivor spaces. After some time it is promoted to the Tenure space.

  • -Xgcpolicy:optthruput (previously default)
    • This algorithm works as MSC (Mark-Sweep-Compact). This means in the first run collector marks live objects, in the second run sweeps unused objects, and compacts the free space. This is being done in parallel. MSC process differs between different JVMs.

  • -Xgcpolicy:optavgpause
    • This policy can be used when the application can't tolerate long pauses in exchange for overall throughput. System tries to determine when next GC would be needed and then runs concurrent GC. before allocating new objects, some GC would be done.

  • -Xgcpolicy:balanced
    • This is a new in V8 collector policy. different regions of a heap map are dealt individually. More information soon




Read more on:

http://publib.boulder.ibm.com/infocenter/javasdk/v6r0/index.jsp?topic=%2Fcom.ibm.java.doc.diagnostics.60%2Fdiag%2Fappendixes%2Fcmdline%2Fcommands_gc.html

Garbage Collection Options and Functions


Garbage collection options:

In addition to one of the previous posts regarding memory management options in various JVMs, now it is time to present some options for the GC (Garbage Collector)

Select specific collector:
  • -XX:+UseSerialGC
  • -XX:+UseParallelGC
  • -XX:+UseParallelOldGC (combine with -XX:+UseParallelGC)
  • -XX:+UseConcMarkSweepGC
  • -Xnoclassgc is to disable garbage collection for permanent generation

Tune the Parallel GC:

  • -XX:ParallelGCThreads=n - limit parallel threads by 'n'
  • -XX:MaxGCPauseMilis=n - limit pause in miliseconds
  • -XX:GCTimeRatio=n - throughput (percentage of CPU time spent on application
Increase debug level:

  • -XX:+PrintGC - get basic information
  • -XX:+PrintGCDetails - get verbose information
  • -XX:+PrintGCTimeStamps - add timestamps
  • -XX:+HeapDumpOnOutOfMemoryError very useful :)

19/04/2013

JVM 64-bit OutOfMemory / Compressed references

If you are running on 64-bit OS and JRockit JVM 64-bit has the heap < 4GB in size and you experience OutOfMemory errors, try disabling compressed references by using the following option in your scripts:

-XXcompressedRefs[=[true|1|false|0]]

or

-XXcompressedRefs:parameter=value

where 1/true stands for enabling the option.
You can also use the following format, when using different heap sizes:


-XXcompressedRefs:enable=true
or
-XXcompressedRefs:size=4GB for Xmx <=2g
-XXcompressedRefs:size=32GB for Xmx <=25g
-XXcompressedRefs:size=64GB for Xmx <=57g



What compressed references does, it limits all pointers (to classes, objects, threads) stored on the heap to 32bits, hence less usage of the heap. 

18/04/2013

Define Heap Size/ Memory management


Define Heap Size/ Memory management

HotSpot
JRockit
Function
-Xmx:[size]

Xmx sets the maximum size of the heap. Maximum value should be the maximum available, but in such a way that it does not cause any error, or about 75% of the system physical memory (depends on the OS).

-Xms:[size]

Xms sets the minimum & initial size of the heap. Recommended to set the same value as the Xmx to minimize allocation overhead of the heap.


-Xmn, -XXNewSize, -XXMaxNewSize

-Xns
Xns sets the size of the Young/ Nursery generation heap. This is the place where new objects land in the first place before being promoted to the other space.

XX:NewSize - Use   this option to set the New generation Java heap size. Can be set to be one-fourth the size of the maximum heap size. Increase the value of this option for larger numbers of short-lived objects.

-XX:MaxNewSize - Use this option to set the maximum New generation Java heap size.

-verbose:gc

-Xverbose:memory

Prints the additional information
-XX:+AggressiveHeap

XXaggressive:memory

Configures the memory system for memory-intensive workloads and sets an expectation to enable large amounts of memory resources to ensure high throughput. The JRockit JVM will also use large pages, if available.

XX:+UseConcMarkSweepGC

Xgc:singlecon

Sets the garbage collector to use a concurrent strategy


XX:+UseParallelGC

Xgc:parallel

Sets the garbage collector to use a parallel strategy



Specifies what to prioritize: even pause times or maximum throughput



Specifies a suitable pause time for the application

-XX:MaxPermSize


Define Maximum heap for the Perm Genaration.
.

(Permanent generation) (non-heap) Stores classes, methods and other meta data



Other settings:


  • -Xss - If the thread stack size (-Xss) has not been set the default value depends on the threading system and the platform you are running on. When using thin threads the minimum thread stack size is 8 kilobytes and the default is 64 kilobytes. When using native threads the minimum thread stack size is 16 kilobytes. For Windows the default thread stack size when using native threads is 64 kilobytes and for Linux it is 128 kilobytes.


  • -XX:SurvivorRatio - The New generation area is divided into several sub-areas: Eden, Survival Space I and Survival Space II. Use the -XX:SurvivorRatio=X option to configure the ratio of the Eden/Survivor Space size. When it is 1:x Eg., -XX:SurvivorRatio=6 - each survivor space will be 1/8 the young generation).

  • –XX:NewRatio=n is used divide heap into old and new generation. If we use. -- XX:NewRatio=5, then you create an old-to-new ratio of 5:1; the old generation occupies 5/6 of the heap while the new generation occupies 1/6 of the heap (-XX:NewRatio=3 - the young generation will occupy 1/4 the overall heap).




Tables were taken from the Oracle website, and changed to suit the blog.


JRockit vs HotSpot JVM Difference


Jrockit was developed by Appeal Virtual Machines and acquired by BEA Systems, and later on acquired by Oracle.
HotSpot is a Java Virtual Machine (JVM) currently hold by Oracle Corporation. 

JRockit is based on the HotSpot JVM by Sun Microsystems, and now Oracle. It has been developed in order to make HotSpot more reliable, and faster to used in server side environment. Jrockit has a slightly bit different heap organisation, garbage collector methods, and optimisations. More information about GC for HotSpot can be found here.


Although JRockit is supposed to have more optimised functions, it is not the rule. Some applications might run faster under HotSpot, and some can be tuned more for JRockit. You don't know it until you try it :)


Additional information:

http://en.wikipedia.org/wiki/JRockit
http://stackoverflow.com/questions/8068717/jrockit-jvm-versus-hotspot-jvm
http://www.oracle.com/technetwork/middleware/jrockit/overview/index.html