You must specify the same value in the initial size (-Xms) and maximum size (-Xmx) of the Java heap. If the values are different, the count of the copy garbage collection might increase.

We recommend this setting even if you do not use the Explicit Memory Management functionality.

Supplement:

If the initial size and maximum size of the Java heap are different, sizes of all areas change at the following timings:

• When the copy garbage collection ends
  The size of the New area changes dynamically.
  
• When the full garbage collection ends
  The sizes of the Tenured area and New area change dynamically.
  

The size of the New area is mainly determined according to the Tenured area size and the value specified in the -XX:NewRatio option.

If the Explicit Memory Management functionality inhibits occurrence of the full garbage collection, the timing of changing the Tenured area size is lost. With this, size of the New area becomes almost fixed.

Therefore, even if you specify a maximum size that is larger than the initial size, the timing of the extension of the New area is lost and the size is the value that you specified as the initial size. If the New area specified in the initial size is small, count of occurrence of the copy garbage collection is more as compared to the case where you do not use the Explicit Memory Management functionality.

• Since an HTTP session is generated, all session attributes (objects) set using the setAttribute method are not released and remain in Explicit heap until you destroy the HTTP session. At that time, it is irrespective whether you have set it in the HTTP session. Therefore, if you do not destroy the HTTP session and repeatedly execute the setAttribute method, the Explicit heap overflows and inhibition of the full garbage collection might not be effective. For confirming whether the Explicit heap overflow has occurred, see 7.13.3 Checking and handling when an Explicit heap overflows in the uCosminexus Application Server System Design Guide.
• If you are not using the automatic release functionality (in the case of -XX:-HitachiExplicitMemoryAutoReclaim), when deleting an HTTP session, objects stored in the session to which there are references from outside, move from the Explicit heap to the Tenured area of the Java heap. In such cases, the used size of the Tenured area increases and occurrence of the full garbage collection cannot be inhibited.
  To prevent movement of objects from the Explicit heap to the Java heap, you must delete references to the objects stored in an HTTP session before deleting the session.
  The same applies to the case where references to objects, which are obtained by using the following API, are remaining:
  
  • getAttribute(String)
  • getAttributeNames()
  Note that if you are using the automatic release functionality (in the case of -XX:+HitachiExplicitMemoryAutoReclaim), the objects do not move to the Tenured area of the Java heap.
  
• In the following cases, objects are placed in the Java heap and not in the Explicit heap:
  
  • If you generate a new session when the number of Explicit memory blocks has reached the maximum value and you cannot create new Explicit memory block (when 1,048,575 Explicit memory blocks are existing at the same time)
  • If the maximum size of the Explicit heap area is exceeded
  • If you could not secure the Explicit memory block
  In these cases, an object is created in the Java heap and hence you might not be able to inhibit occurrence of the full garbage collection.
  
• In JSP, the HttpSession object is implicitly created, by default. To prevent the Explicit heap overflow caused by generation of unnecessary HttpSession objects, perform the settings in such a way that the HttpSession object is not explicitly created in JSPs that do not require session. Use the session attribute in page directive to perform the setting.
• When executing a test to validate the effect of the full garbage collection inhibition, do not use a condition such as the continuous generation of sessions without destroying the sessions. Because Explicit memory blocks are not released, there is a high possibility of Explicit heap overflow.
  The Explicit memory blocks are reserved for release when a session is destroyed and released when the garbage collection occurs thereafter. Therefore, even if you have destroyed the session, if repetition count of session destruction and generation is too high for one garbage collection interval, other Explicit memory blocks get created while Explicit memory blocks reserved for release remain. As a result, the number of Explicit memory blocks increases and the Explicit heap might overflow.
  To validate the effect of the full garbage collection inhibition, execute a test using conditions that appropriately manage the sessions.
  
• The objects, which you have stored in a session, are placed in the Java heap immediately after generation. After the copy garbage collection is executed for several times, the objects move to the Explicit heap, usually at the timing of rising to the Tenured area. Therefore, if objects are deleted in a short time or if the session is quickly destroyed, the objects are not placed in the Explicit heap.

The name of the Explicit memory block is output to Explicit heap details that are output to the thread dump of JavaVM. The maximum limit for the number of characters in the name of an Explicit memory block is 2,000 characters. If you set a name of an Explicit memory block exceeding 2,000 characters in the setName method of the JP.co.Hitachi.soft.jvm.MemoryArea class, the name part which exceeds 2,000 characters is not output to the thread dump.