Problem: Thread throwing OutOfMemoryError  found

Details This dump was generated after the thread below threw OutOfMemoryError. This may be caused by one or more of the following things: - your heap is too small - your app wastes memory somewhere - your app has a memory leak - your app tries to allocate an array bigger than the JVM limit See other report sections for more concrete clues and solutions. Found thread with name: UNKNOWN For full details, go to Section 2. Thread throwing OutOfMemoryError

Problem: High percentage of memory is used by instances of some class(es).

Details Instances of some class(es) take up a big percentage of memory. That can happen when the number of instances is very high, or their size is very large (e.g. for arrays). Depending on whether all these instances are really necessary or not, and also whether they are live or garbage, this may or may not be a problem. See other report sections for more details about these objects. Threshold exceeded for:   Total size   Source   539,407Kb (52.9%) Objects of class String  416,565Kb (40.8%) Objects of class io.vertx.core.parsetools.impl.JsonEventImpl For full details, go to Section 3. Where Memory Goes, by Class

Problem: High percentage of memory retained by one or more GC roots, or memory leak.  Leak candidate(s) found

Details Some GC root(s) retain a large percentage of memory, and/or there are signs of a memory leak. When one GC root holds most of the objects, it may be by design, or it may signal that more objects than expected are accumulated in memory. Alternatively, when a single object, typically a collection or array, references a very large number of other objects, AND they take up a lot of memory, it may signal a memory leak. However, we cannot say for sure that you have a real problem here. You need to inspect carefully the object trees in the report section below and check whether they match your expectations. For general discussion of this problem, see this article. Found leak candidate(s) in Object tree for GC root(s) Java Static [org.folio.oaipmh.processors.MarcWithHoldingsRequestHelper.INSTANCE], Java Local(org.folio.oaipmh.processors.MarcWithHoldingsRequestHelper) [1 object(s)] (1 thread(s)) Threshold exceeded for:   Total size   Source   1,004,830Kb (98.5%) Object tree for GC root(s) Java Static [org.folio.oaipmh.processors.MarcWithHoldingsRequestHelper.INSTANCE], Java Local(org.folio.oaipmh.processors.MarcWithHoldingsRequestHelper) [1 object(s)] (1 thread(s)) For full details, go to Section 4. Where Memory Goes, by GC Root

Problem: Memory is wasted due to per-object overhead of instances of some class(es).  Overhead 37.5%  ( 382,491Kb )

Details A big percentage of memory is used by per-object, internal JVM data (object headers). Each object in the heap has a fixed-size header, where the JVM keeps data such as a pointer to the object's class, lock bits, etc. In HotSpot JVM, the most common header size is 12 bytes for an ordinary object and 16 bytes for an array. When the heap size is over 32G, this becomes 16 bytes and 20 bytes respectively. In Android JVM, object headers are smaller. When there is a very large number of small objects in the heap, the percentage of memory used by their headers can become quite big. You need to check whether all these objects are necessary, or whether they can be combined with other objects to reduce their total number. For general discussion of this problem, see this article. Threshold exceeded for:   Overhead   Source   156,212Kb (15.3%) Per-object overhead of io.vertx.core.parsetools.impl.JsonEventImpl  112,164Kb (11.0%) Per-object overhead of byte[]  112,142Kb (11.0%) Per-object overhead of String For full details, go to Section 6. Fixed per-object overhead

Problem: Memory is wasted by duplicate strings.  Overhead 37.6%  ( 383,345Kb )

Details There are multiple String instances with the same value, like "yes", "yes", "no", "no", "no". String duplication often occurs when, for example, an app reads the same common word such as "yes" from the DB repeatedly, creating a new String instance every time. See the report section below for concrete findings and suggestions how to fix. For general discussion of this problem, see this article. Threshold exceeded for:   Overhead   Source   178,516Kb (17.5%) Copies of string "false"  89,258Kb (8.7%) Copies of string "MARC" For full details, go to Section 8. Duplicate Strings

Problem: Memory is wasted by duplicate objects other than Strings.  Overhead 11.7%  ( 119,033Kb )

Details There are some duplicate objects, such as io.vertx.core.parsetools.impl.JsonEventImpl. That is, there are multiple instances of some class(es) with the same contents. Object duplication often occurs when, for example, an app reads the same frequently used piece of data from the DB repeatedly, creating a new Java object for it every time. See the report section below for concrete findings. For general discussion of this problem, see this article. Threshold exceeded for:   Overhead   Source   59,508Kb (5.8%) Copies of objects with value io.vertx.core.parsetools.impl.JsonEventImpl(token : com.fasterxml.jackson.core.JsonToken@d4721d08, type : io.vertx.core.parsetools.JsonEventType@d4cd7c50, field : null, value : null)  59,507Kb (5.8%) Copies of objects with value io.vertx.core.parsetools.impl.JsonEventImpl(token : com.fasterxml.jackson.core.JsonToken@d4721cd8, type : io.vertx.core.parsetools.JsonEventType@d4cd7640, field : null, value : null) For full details, go to Section 13. Duplicate Objects

Problem: Memory is wasted by duplicate primitive arrays.  Overhead 20.3%  ( 206,854Kb )

Details There are some duplicate primitive arrays, such as byte[] and int[]. That is, there are multiple arrays with the same elements in the same order. Duplication of primitive arrays often occurs when, for example, an app reads the same frequently used piece of data, such as an image, from the DB repeatedly, creating a new Java array for it every time. See the report section below for concrete findings. For general discussion of this problem, see this article. Threshold exceeded for:   Overhead   Source   89,258Kb (8.7%) Copies of arrays with value byte[5]{'false'}  44,629Kb (4.4%) Copies of arrays with value byte[4]{'MARC'} For full details, go to Section 14. Duplicate Primitive Arrays

Problem: High amount of off-heap memory allocated via java.nio.DirectByteBuffer objects.  Overhead 20.3%  ( 207,195Kb )

Details A considerable off-heap memory is allocated and retained by java.nio.DirectByteBuffer objects in this app. Depending on whether all these buffers are really necessary or not, and also whether they are live or garbage, this may or may not be a problem. Note that a garbage (unreachable) DirectByteBuffer Java object still retains off-heap memory. That memory area is released only when the GC gets to this Java object and wipes it out. Sometimes that takes a lot of time. See the report section below for concrete findings. For general discussion of this problem, see this article. For full details, go to Section 18. Off-heap memory used by java.nio.DirectByteBuffers

Problem: Some potentially humongous objects are found  Overhead 5.4%  ( 54,843Kb )

Details There are some objects bigger than 1MB, such as Object[] and byte[]. Big objects are generally more expensive for the JVM to handle. This is especially true for the G1 GC, where any object bigger than half a GC region size is considered a humongous object. Such objects are allocated directly in the Old Generation into special "humongous regions", that are contiguous sets of ordinary regions. A humongous allocation often requires extra work from the GC. Collecting humongous objects is also more expensive than collecting normal objects. Thus if you see any potentially humongous objects reported for your heap dump, you may want to check your actual GC region size, and then check your GC log for any records of Humongous object allocations. Normally, G1 region size is 2MB for heap < 4G, 4MB for heap < 8G, 8MB for heap < 16GB and so on. If there are many humongous objects, you may need to consider reducing their size, increasing region size, increasing heap size, or all of the above. For general discussion of this problem, see this article, "Humongous Objects" section. Threshold exceeded for:   Overhead   Source   52,063Kb (5.1%) Instances of Object[] For full details, go to Section 19. Humongous (bigger than 1MB) objects