The marking stack used by MarkSweep currently uses a GrowableArray<oop>.  That's overkill, since we only use the marking stack as a stack.  In contrast, GrowableArray implements an array, so when it expands, it reallocs and copies the whole array to a new, larger, piece of contiguous memory.  Since the marking stack is often large, this often requires a large contiguous chunk of memory, which can be difficult to acquire.  Since GrowableArray grows by doubling, on average 25% of the array will be empty.  When the marking stack is large, this can be a substantial waste of space.  

Instead, the stack could be implemented as a chained series of small regions.  This could allow us to balance the storage for the chain pointers  against the increment of growth, to use an appropriate amount of space in modest chunks.
Posted Date : 2006-05-08 23:47:21.0

N/A

Since the mark sweep algorithm is used as a backstop collector for many of our collectors (e.g., -XX:+UseParallelGC, -XX:+UseParNewGC, -XX:+UseConcMarkSweepGC) in addition to its obvious use with -XX:+UseSerialGC, this issue may be present in non-obvious places.
Posted Date : 2006-06-16 22:06:11.0

The preserved_mark_stack and preserved_oop_stack used by mark sweep and CMS should also be converted to GrowableStacks (assuming they are used only as stacks).  Scott Marlow of <company unknown> was testing the growable marking stacks fix and his JVM died when trying to allocate an 80MB preserved mark stack.
Posted Date : 2009-01-07 23:17:45.0

Still more stack types that should be converted:  the stacks used by parallel collectors to handle task queue overflows; promotion failure scan stacks, revisit klass stacks, revisit mdo stacks.  Changing the synopsis to broaden the scope.
Posted Date : 2009-09-21 05:47:17.0

It appears that this is not only a problem with MarkSweep.  I am seeing this when the heap tries to grow and I am not using MarkSweep.

I think this bug is duplicate of closed 5048441,
Our Java Servers fails with comments given below. I have seen this problem 3 times last week,but I cant reproduce it.
JVM parameters are -Xconcurrentio XX:+UseLWPSynchronization -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -Xms2048m -Xmx2048m

Servers heavily use JNI.
Server uses more than 1GB memory.
I have seen SIGSEGV and SIGBUS errors, too.

System definition:
-----------------------------
Sun Solaris,
java version "1.5.0_08"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_08-b03) Java HotSpot(TM) Server VM (build 1.5.0_08-b03, mixed mode)

error output
------------------
Exception java.lang.OutOfMemoryError: requested 8192000 bytes for GrET* in /BUILD_AREA/jdk1.5.0_08/hotspot/src/share/vm/utilities/growableArray.cpp. Out of swap space?

This seems to be a scalability limitation when using Java with certain types of memory intensive applications.  It would be great to have a solution in a Java 5 release or at least a Java 6 release.  

I voted for this bug and would like to see the priority increased as a lot of people have hit this problem (not everyone has a native memory leak or one of the other possible causes).  I hope that others also vote for this bug.

Regarding the solution, you are probably already considering this, but I'll mention it anyway.  With your solutions chained series of small regions, if each region is a fixed size, it could be quick to compute which region contains the desired element.  

To the person working on this bug, thanks for helping to resolve this issue, if you send me email when it is fixed in Java 5 or Java 6, I'll happily send your favorite chocolates :-)

I'll see Scott's chocolate and raise it a beer. Our app is memory-intensive, but we're not running out of heap and we're not using any leaky JNIs - the only OutOfMemory we're hitting is this one. This is a more serious issue than "request for enhancement" would suggest.

I have a same error occur.
[Full GC
Exception java.lang.OutOfMemoryError: requested 131072000 bytes for GrET* in C:/BUILD_AREA/jdk1.5.0_14/hotspot\src\share\vm\utilities\growableArray.cpp. Out of swap space
Please, can someone respond with a suggestion?

Does anyone have any ideas of how we can configure the JVM to reduce the chances of this problem? It has happened to me twice in the past two months.

Can we allocate JVM memory to size X and configure garbage collection to always occur before some safety amount Y of memory is used? I'm guessing that if this could be done that we would always have extra space for memory usage that we have zero control over (like this issue)

Here are the Hotspot options available, but I don't see a way to do this based on my current understanding of the available options:

http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp

To the previous commenter: Essentially: No, there's no way to "configure the JVM" to avoid this problem.  The bug is that we need a large contiguous region of C malloc space, and when virtual address space is tight, or the malloc area is fragmented, we can't get that space.

What JVM flags are you using already?  What kind of machine are you running on?  How much live data do you have in your heap (the size of the heap after a full collection)?

I'm hitting the same issue on 1.6.0_04.  

#
# An unexpected error has been detected by Java Runtime Environment:
#
# java.lang.OutOfMemoryError: requested 41711080 bytes for GrET in C:\BUILD_AREA\jdk6_04\hotspot\src\share\vm\utilities\growableArray.cpp. Out of swap space?
#
#  Internal Error (allocation.inline.hpp:42), pid=8872, tid=8692
#  Error: GrET in C:\BUILD_AREA\jdk6_04\hotspot\src\share\vm\utilities\growableArray.cpp

I'm curious if this issue is less prevalent when running on a machine with a 64-bit OS. We have an application that periodically crashes due to this bug. I know it's a loaded question - but would moving it from a 4GB 32-bit Wintel machine to a 12GB 64-bit OS machine (potentially) make it less likely to trip this?

charper,

I saw this same error occur on 64-bit as well as 32-bit.  

Same error (in growableArray.cpp) the first time here on our server app (Windows 2000 SP4, 2 GB RAM) with JDK 1.6.0_05 for "no reason" (as the running jobs are not very memory intense).

I am unhappy to report this problem happens in version 1.6.0_10. Running 32bit JRE on WinXP64. Plenty heap space left (only using about 128M out of a 512M heap), but having lots of threads.

Why is this a request for enhancement? Applications crash due to internal JVM issues over which the users have no control. That looks like a bug to me and if it was marked as such,  it would make the Top 25 list.

I wonder if Microsoft ever pondered whether the Blue Screen of Death is a bug or something of an enhancement. At least they can blame it on the hardware.

Serban

Now we have this error almost twice a day on production environment.
And I'm shocked, reading history and comments of this bug.
Now we are trying to divide our application (separate some application) on several tomcats to avoid this problem (as a work around).

# java.lang.OutOfMemoryError: requested 2048000 bytes for GrET in C:\BUILD_AREA\jdk6_07\hotspot\src\share\vm\utilities\growableArray.cpp. Out of swap space?
#  Internal Error (allocation.inline.hpp:42), pid=7888, tid=5676
#  Error: GrET in C:\BUILD_AREA\jdk6_07\hotspot\src\share\vm\utilities\growableArray.cpp
# Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86)
---------------  T H R E A D  ---------------
Stack: [0x6ac30000,0x6ac70000]
[error occurred during error reporting (printing stack bounds), id 0x80000001]
VM_Operation (0x6c9cf8c4): GenCollectFull, mode: safepoint, requested by thread 0x6bd33c00
---------------  S Y S T E M  ---------------
OS: Windows Server 2003 family Build 3790 Service Pack 2
CPU:total 2 (2 cores per cpu, 1 threads per core) family 6 model 15 stepping 11, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3
Memory: 4k page, physical 2097151k(1140084k free), swap 4194303k(2858720k free)
vm_info: Java HotSpot(TM) Client VM (10.0-b23) for windows-x86 JRE (1.6.0_07-b06), built on Jun 10 2008 01:14:11 by "java_re" with MS VC++ 7.1

The same problem encountered on our production servers. The only information we could see on the begining in Windows "Event Viewer" is "The Apache Tomcat service terminated unexpectedly.  It has done this 19 time(s)."  After that we had to change debug level of our applications, tomcat server and we started to watch activity of GC. As the result we've got: 
# java.lang.OutOfMemoryError: requested 2048000 bytes for GrET in C:\BUILD_AREA\jdk6_07\hotspot\src\share\vm\utilities\growableArray.cpp. Out of swap space?

As I can see I'm not the only who looks out for effective solution.

Best regards.

I upgraded to 6u12 and problem seemed to go away.  Made me very happy :)

The same error has appeared in production! (Solaris10 + Sun One AS8.2) We have tested the system with LoadRunner scripts and there is a really strange think I can't understand. The Sun appserver crashes even with 10 concurent users while a JBoss can handle 100 concurent users with no problem (with the same JVM of course). Is it possible that the memory get much more fragmented under Sun's as?
Our customer is a bank and it is really a shame to restart the appserver THREE times a day. Btw how could it be a request for enhancement?

Same problem with 1.6.0_13

#
# An unexpected error has been detected by Java Runtime Environment:
#
# java.lang.OutOfMemoryError: requested 131072000 bytes for GrET in /BUILD_AREA/jdk6_13/hotspot/src/share/vm/utilities/growableArray.cpp. Out of swap space?
#
#  Internal Error (allocation.inline.hpp:42), pid=16129, tid=209042352
#  Error: GrET in /BUILD_AREA/jdk6_13/hotspot/src/share/vm/utilities/growableArray.cpp
#
# Java VM: Java HotSpot(TM) Server VM (11.3-b02 mixed mode linux-x86)
# An error report file with more information is saved as:
# /tmp/hs_err_pid16129.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

There has been some work on this, but where is this patch implemented?

And is it tested?

http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2008-November/000307.html

We hit the same problem with Sun JVM 1.4.2 on Solaris 9 with plenty physical memory and adequate SWAP spaces. This is preventing us from serving the monthly bill to one of the largest clients with millions call records. Any indication from Sun when and on which version this bug would be fixed? Thanks.

We are also getting the same problem very frequenty. Can some one suggest the solution please 

Same error with CMS occurring with 3GB Java Heap (large old space) when the GrowableArray is allocating 32 or 64 MB chunks.  This occurs across 5 instances of an application on average once every 4 days but is consistent.

+1 vote and 1 pint of beer

I am having this exact error in production environment, every 3-4 days .... have tried all the GC flavors

I got the same error. 

# An unexpected error has been detected by Java Runtime Environment:
#
# java.lang.OutOfMemoryError: requested 655360 bytes for GrET in C:\BUILD_AREA\jdk6_05\hotspot\src\share\vm\utilities\growableArray.cpp. Out of swap space?
#
#  Internal Error (allocation.inline.hpp:42), pid=4276, tid=5364
#  Error: GrET in C:\BUILD_AREA\jdk6_05\hotspot\src\share\vm\utilities\growableArray.cpp
#
# Java VM: Java HotSpot(TM) Server VM (10.0-b19 mixed mode windows-x86)


---------------  S Y S T E M  ---------------

OS: Windows Server 2003 family Build 3790 Service Pack 2

CPU:total 4 (8 cores per cpu, 1 threads per core) family 6 model 13 stepping 1, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3

Memory: 4k page, physical 2097151k(2047768k free), swap 4194303k(4093948k free)

vm_info: Java HotSpot(TM) Server VM (10.0-b19) for windows-x86 JRE (1.6.0_05-b13), built on Feb 22 2008 01:12:21 by "java_re" with MS VC++ 7.1

Same here on J2SE 1.6.0_10 on Windows 2000 Server with lots of Java memory free/available. Our server also runs 24/7 and the time it crashed, over 6000 threads were processed (which itself can consume large amounts of memory for XML, PDF processing). Many threads starting and dying => large memory fragmentation => this crash?

If you are running into this error on a 32-bit Windows JVM _and_ you have the JVM configured to a near-maximum heap size (e.g. -Xmx1550m) _and_ you have lots of threads (in our case, about 300), then the process is running very near the 32-bit address space limit.

In this situation, lowering the max heap size can give you enough address space 'headroom' to avoid triggering the allocation failure.

This is definitely a bug not an enhancement. The mysterious part is that our customer only sees this issue on one node of the cluster.