Bug ID: JDK-6306912 java.lang.OutOfMemoryError trying to allocate JvmtiTagHashmapEntry* or JvmtiTagHashmapEntry

Type: Bug
Component: hotspot
Sub-Component: jvmti
Affected Version: 6

Priority: P4
Status: Closed
Resolution: Won't Fix
OS: generic
CPU: generic

Submitted: 2005-08-05
Updated: 2023-12-13
Resolved: 2016-11-03

We have got a report from our customer who received the following
messages profiling his application:

LH> Exception java.lang.OutOfMemoryError: requested 16 bytes for CHeapObj-new. Out of swap space?

and

LH> Exception java.lang.OutOfMemoryError: requested 314572876 bytes for JvmtiTagHashmapEntry* in /BUILD_AREA/jdk1.5.0_03/hotspot/src/share/vm/prims/jvmtiTagMap.cpp. Out of swap space?

(The entire message is quoted below.)

Looks like massive object tagging causes a problem for an application
with lots of objects.

I found nothing in the JVMTI specification saying about possible
limitation of the number of objects that can be tagged at a time. Is
this a known problem? Is there a way to tweak JVM in command line to avoid the
problem?

This is not on our list of current priorities, if this changes please re-open this issue.
03-11-2016
EVALUATION -- One other thing to mention is that mustang has a built-in heap dumper which can be used in low-memory situations. If you run with -XX:+HeapDumpOnOutOfMemoryError then a heap dump will be created when the first java.lang.OutOfMemoryError is thrown because the heap is full (or perm gen is full). A heap dump can also be obtained from a running application using jmap. Since b53 this can be done on all platforms using "jmap -dump:file=<file> <pid>". This will request the application with process-id <pid> to dump its heap to <file>. The JDK also includes the utility jhat which can be used to browse the heap. Note that a heap dump + jhat don't offer the same functionality as a complete and rich profiler. However they can be useful in situations like this where the user is running on a system that doesn't have sufficient virtual memory available to run with a native agent.
15-09-2005
EVALUATION In mustang b51 we have improved the implementation as follows: 1. The load factor on the hashmap has been increased 2. If there isn't sufficient memory to resize the hashmap then it is not fatal (a warning will be emitted) 3. Previously when objects were untagged we put the hash map entries onto a free list for late use. Now we limit the length of the free list so that memory is released. 4. Diagnostic output from +TraceJVMTIObjectTagging has been improved so that memory usage information is printed.
31-08-2005
EVALUATION We received a number of fatal error logs which demonstrate the issue. These show that the process is hitting the ~3GB limit (the system is RedHat FC3 which is obviously compiled to limit the process to ~3GB). When we look at the memory maps we see that 2.6GB is reserved for the java heap so this leaves 400MB for the VM, libraries, and everything else. This is just not sufficient for the amount of objects that need to be tagged. We see that that OOME sometimes happens when trying to expand the hashmap for the object tags. One small improvement is that we can increase the load factor on the hashmap but the overall issue still remains. From one of the logs we can deduce that there are about 14.7 million objects tagged at the time of the crash. This equates to about 225MB for the hashmap entries as each one requires 16 bytes on a 32-bit system. There are other overheads but the bulk of the memory usage is for hashmap entries. Given that there isn't an easy solution to this issue the following options should be explored by the user: 1. Reduce the size of the java heap - does this application really need a 2.6GB heap? Could it be reduced to <2GB for example? 2. Re-compile kernel to allow ~4GB of virtual memory 3. Move to a 64-bit system where the 3GB limit does not apply ---
19-08-2005
EVALUATION Object tags are maintained in a hashmap that is outside of the java heap. Each object tag requires an entry in the hashmap plus a JNI weak reference. The allocation of any of these resources can fail in low memory conditions and the VM will terminate. One specific case that we should address is the case when the hashmap attempts to resize in low memory conditions. Reszing involves the allocation of a larger hashmap and entries are re-hashed from the old to the new hashmap. This could be made more resiliant so that we continue in the case where a new (larger) hashmap cannot be allocated. It has also been suggested that we reducing the number of resizes (make the initial hashmap larger). ---
05-08-2005