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   166,724Kb (16.3%) Objects of class byte[]  142,339Kb (13.9%) Objects of class org.netbeans.lib.lexer.token.DefaultToken  130,352Kb (12.8%) Objects of class org.netbeans.modules.php.editor.lexer.PHP5ColoringLexer$LexerState 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.netbeans.modules.editor.lib2.highlighting.SyntaxHighlighting.globalFCSCache Threshold exceeded for:   Total size   Source   536,684Kb (52.5%) Object tree for GC root(s) Java Static org.netbeans.modules.editor.lib2.highlighting.SyntaxHighlighting.globalFCSCache  262,527Kb (25.7%) Object tree for GC root(s) Java Static org.netbeans.modules.editor.hints.AnnotationHolder.file2Holder 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 27.7%  ( 283,158Kb )

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   53,377Kb (5.2%) Per-object overhead of org.netbeans.lib.lexer.token.DefaultToken  52,270Kb (5.1%) Per-object overhead of byte[] For full details, go to Section 6. Fixed per-object overhead

Problem: Memory is wasted by primitive arrays with many zeroes and/or other problems.  Overhead 14.1%  ( 144,316Kb )

Details There are some primitive arrays, such as byte[] and char[], with high overhead per element. Each primitive array has a fixed-size internal, JVM-managed header, with most common size of 16 bytes in HotSpot JVM and 12 bytes in Android. Each array slot takes memory as well. Thus an empty array (with all elements equal to 0) wastes all its memory. Consider creating such arrays lazily. Another common problem is underutilized buffers: arrays where less than a half of the capacity is ever used. See if such buffers can be allocated with more appropriate capacity. When an array contains just one or two elements, you may in some situations be able to store these elements more economically, e.g. as data fields in the enclosing class, or at least make sure you create the array with the correct (small) size. Otherwise, the memory used by the array internals vs its payload is disproportionally high. See the report section below for concrete findings. Threshold exceeded for:   Overhead   Source   76,203Kb (7.5%) 1-length byte[] arrays For full details, go to Section 11. Bad Primitive Arrays

Problem: Memory is wasted by duplicate primitive arrays.  Overhead 17.0%  ( 174,007Kb )

Details There are some duplicate primitive arrays, such as byte[] and char[]. 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   76,201Kb (7.5%) Copies of arrays with value byte[1]{0} For full details, go to Section 14. Duplicate Primitive Arrays

Problem: Some potentially humongous objects are found  Overhead 9.1%  ( 93,445Kb )

Details There are some objects bigger than 1MB, such as char[] and int[]. 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   56,483Kb (5.5%) Instances of char[]  30,131Kb (2.9%) Instances of int[] For full details, go to Section 19. Humongous (bigger than 1MB) objects