7.14.2 Notes on using Explicit heap in objects related to an HTTP session

• 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 repeat executions of the setAttribute method without destroying the HTTP session, an Explicit heap overflow might occur, preventing you from gaining the effect of suppressing Full GC. For confirming whether the Explicit heap overflow has occurred, see 7.14.3 Checking and measures when there is an overflow from the Explicit heap 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. Because this increases the size of the used Tenured area, occurrence of Full GC cannot be suppressed.

  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 the preceding cases, you might not be able to suppress occurrence of Full GC because objects are created in the Java heap.

• 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 you evaluate the effect of suppressing occurrence of Full GC, do not run a test under conditions where successive session creations continue without destroying the session. Because Explicit memory blocks are not released, there is a high possibility of Explicit heap overflow.

  Note that for Explicit memory blocks, a reservation for release is made when the session is destroyed. The Explicit memory blocks are released when GC occurs subsequently. If session destruction and generation are repeated too many times within one GC interval, creation of new Explicit memory blocks can occur while reservations for releasing Explicit memory blocks remain. As a result, the number of Explicit memory blocks increases and the Explicit heap might overflow.

  When you evaluate the effect of suppressing occurrence of Full GC, run a test under conditions where sessions are managed appropriately.

• The objects, which you have stored in a session, are placed in the Java heap immediately after generation. After copy GC occurs several times, normally, the objects move to the Explicit heap at the time when they are promoted 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.

To Page Top