--------------------------------------
Test         : nsk/regression/b4432433
TestBase        : testbase_nsk 
VM              : server , client
Mode            : comp . mixed
Platform (s)	: solx86 , rh7.2
----------------------------------------

Error output (for solx86)
sh std-doit.sh
/net/alpheridies/export/VM/hopper/weekly/JDK/latest/solx86/bin/java -client -DHA
NGINGJAVA -client -Xmixed -Xmx1024m b4432433 1024

Exception java.lang.OutOfMemoryError: requested 1048592 bytes
Status = 1
------------------------------------------------
/net/alpheridies/export/VM/hopper/weekly/JDK/latest/solx86/bin/java -client -DHA
NGINGJAVA -client -Xcomp -Xmx1024m b4432433 1024

Exception java.lang.OutOfMemoryError: requested 1048592 bytes
Status = 1
------------------------------------------------
/net/alpheridies/export/VM/hopper/weekly/JDK/latest/solx86/bin/java -server -DHA
NGINGJAVA -server -Xmixed -Xmx1024m b4432433 1024

Exception java.lang.OutOfMemoryError: requested 28835840 bytes
Status = 1
------------------------------------------------
/net/alpheridies/export/VM/hopper/weekly/JDK/latest/solx86/bin/java -server -DHA
NGINGJAVA -server -Xcomp -Xmx1024m b4432433 1024

Exception java.lang.OutOfMemoryError: requested 28835840 bytes
Status = 1
------------------------------------------------
***** Please Note*******
This has been reported since 1.4.1-beta-b06. THe information was added to an exiting bug b4432433. Since that bug was already in Integrated state when this additonal comment was added, not sure if this is getting tracked. Hence
Opening a new bug for better tracking
************************************
Steps to reproduce:
----------------------
1. cd /net/sqesvr.eng/export/vsn/GammaBase/Bugs/{BugID}
2. sh doit.sh


  xxxxx@xxxxx   2002-06-05


  xxxxx@xxxxx   2003-04-24

In the past, we have seen VM exits that appeared
to be due to running out of memory (no OutOfMemory
exception - just a VM exit).  A little digging on this
led us to the following bug report:

http://developer.java.sun.com/developer/bugParade/bugs/4697804.html

The specific problem described in this bug that concerns us
is the potential for the VM to simply exit when it can't
expand the heap, rather than throw an OutOfMemory exception
that would allow the application to continue and/or recover.

We are doing our best to work around this by following the
recommended practices of configuring enough swap and setting
-Xms equal to -Xmx.  Unfortunately we can't really control our
customers swap configurations (can only make recommendations) and
so we feel compelled to use the Xms = Xmx workaround which is
really inefficient in many cases.
  xxxxx@xxxxx   10/27/04 21:58 GMT

Disable VM heap resizing by setting -mx and -ms to the same value.

This will prevent us from hitting the most common sources of the
vm_exit_out_of_memory exits.

  xxxxx@xxxxx   2002-07-11

The best thing to do is increase swap size on the machines encountering
this error. 

  xxxxx@xxxxx   2003-01-30

Sometimes when the VM is in a low-resource situation, it currently
cannot throw an OutOfMemory error because the heap is corrupt -- no
further Java code can run. This often happens when we're trying to 
expand the heap and cannot successfully malloc space for the supplemental
data structures that we need.

When this happens, the VM prints OutOfMemory and exits (cleanly, rather
than with a fault).

(see bug 4317486 [sol/c1/b04] assert generation.cpp 469 during scavenge.)

We should try to ensure we can never get into such a state by atomically
allocating all data that we require, so we can roll-back to a consistant
heap state.

I haven't yet found where exactly we're calling vm_exit_out_of_memory
for this test case (and it might change from machine to machine, depending
on how many resources we have)... but doing so might give us a good place
to start cleaning this up.

Please note that in typical use, users are not trying to provoke
OutOfMemory exceptions. If they hit this condition, they'd see an indication
of what went wrong, e.g.
  Exception java.lang.OutOfMemoryError: requested 1048592 bytes
and the VM will exit. This at least indicates a possible solution (bumping
-Xmx and perhaps -Xms). 

This doesn't help deployed Java applications, though, that might catch the
OutOfMemory error and more robustly handle the situation, so anything changes
we can make to allow the error to be thrown would be useful.

  xxxxx@xxxxx   2002-06-06



The customer test case from the JDC comments shows one of the scenarios
where we can exit the VM:  when we're attempting to resize the heap after
a GC and cannot get enough resources to do so. Growing the heap is
actually implemented as a multi-step process, as we also grow supporting
data structures for the heap. 

Ideally, if one of these steps fail we should roll back to a known good
heap state.  I'm looking into how to do that for the mantis time frame.

Note there are other failure modes which also need to be looked at.
  xxxxx@xxxxx   2002-07-08

Committing to fix the most common causes of this problem for Mantis, 1.4.2.

  xxxxx@xxxxx   2002-07-11


Further work showed us that while fixing the common cause of this, we
just moved the problem:  typically  we'd still get unrecoverable errors
and there was simply nothing Java code could do to attempt to clean up.

This is a very difficult problem to solve. We are working on some possible
solutions, but our best suggestion for users running into this problem is
to avoid the problem by increasing swap space on their machines so they
have enough to cover the Java application's needs plus all other applications
running on the machine at the same time.

  xxxxx@xxxxx   2002-08-29


  xxxxx@xxxxx   2005-2-04 19:22:49 GMT
Adding some of the explanations in the JDC comments.

Q. Could you change the implementation to use data structures of a fixed size, pre-allocated so that errors just send you back to a known state?

A. Regarding the comment about using pre-allocated fixed size data structures to avoid the problem of the JVM not being able to get additional memory during a garbage collection, the garbage collector does use pre-allocated data structures.  However, there are data structures that may need space that is proportional to the amount of live data in the heap.  It is very unusual that this actually occurs so space is not pre-allocated for this contingency (because such pre-allocated space would not be available to the application). Rather a fixed amount of space is pre-allocated and more is requested only in the rare situations where it is actually needed.  Also there are a  few situations where the JVM has requested that the operating system reserve space for the JVM and when the space is actually needed, it is not available.

Q. How about simply releasing the jvm memory consumed and returning to a fresh state so it can continue servicing new calls and throw a error for existing processes that were consuming memory.

A. Regarding the comment from the respondent, if I understand correctly, you are asking if an out-of-memory can be sent only to the thread that is consuming memory and resulted in the JVM calling vm_exit_out_of_memory().  As relates to 4697804 the JVM is trying to get memory so that it can complete a garbage collection.  As such there is no free space in the Java heap so that any request for the allocation of an object from any thread would fail. The JVM could release all its ancillary data structures but that doesn't change  the fact that the Java heap needs to be collected.
Posted Date : 2006-03-09 23:43:21.0

CR 6405799 concerns object marking code which 
can sometimes cause a vm_exit_out_of_memory() if there
is not enough swap space to expand the C-heap.  This
code currently uses more space for better performance
but is being examined to determine if less space can
be used without too large a loss of performance.  If
a reasonable tradeoff can be reached, a change regarding
that CR will fix an instance of calling vm_exit_out_of_memory()
not previously identified.
Posted Date : 2006-04-24 22:16:00.0

The same problem exists on Windows 2000. It's almost 
inevitable when the maximum heap size is larger than the 
available memory; if the VM can't expand the heap it exits 
without giving the application a chance to handle the error.

Simple example:

    import java.util.*;

    public class Bug4697804 {
        public static void main(String[] args) {
            try {
                create(2, 1024);
            }
            catch (OutOfMemoryError err) {
                System.err.println("OutOfMemoryError - OK");
            }
        }
        private static Object create(int d, int n) {
            List x = new ArrayList(n);
            if (d > 0) {
                for (int i = 0; i < n; ++i) {
                    x.add(create(d-1, n));
                }
            }
            return x;
        }
    }

With heap size defaults this runs as expected, but with a 
maximum heap size larger than the available memory it fails 
with the error described:

    > java -version
    java version "1.4.0"
    Java(TM) 2 Runtime Environment, Standard Edition (build 
1.4.0-b92)
    Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)

    > java Bug4697804
    OutOfMemoryError - OK

    > java -Xmx512m Bug4697804
    Exception java.lang.OutOfMemoryError: requested 4112 
bytes

Alternatively, the application aborts with an operating 
system error:

    java.exe - Application Error
    The exception unknown software exception (0xc00000fd) 
occurred in the application at location 0x78004fc3.

This is a serious problem for us. We have an end-user 
application where the memory use depends on how many 
objects users choose to create, and the level of complexity 
they choose to employ. We want memory to be limited only by 
what the machine can stand, so we start up with a large 
maximum heap on the assumption that the VM will expand as 
much as it can and then throw an OutOfMemoryError. When the 
VM exits, we get no opportunity to save users' work.

The only workaround I have is to start the VM with a fixed-
size heap (-Xms the same as -Xmx) within the limit of 
available memory, but that's guaranteed to be restrictive 
in some cases and wasteful in others. Also I worry whether 
there are other conditions which can provoke the same error.

Any better workarounds gratefully received; also any 
prognosis of when this might be fixed.

I get the java.lang.OutOfMemoryError when returning a 
ResultSet greater than 5000 rows from a JSP three tier 
application.  How do I disable VM heap resizing by setting -mx 
and -ms?  

On Win2K the -Xms and -Xmx doesn't seem to restrict the 
size of heap at all.  When it reaches the value set by -Xmx 
the JVM continues to allocate itself more memory.  I have
512MB of physical RAM and tried setting -Xms192m -
Xmx192m, but JVM continues to go beyond 192MB and 
continues until the memory is totally exhausted on the system.

sananikone, remember when you're specifying a max heap size
with -Xmx that you're specifying the size of the heap, not
the total memory used by the VM...I'm specifying a max heap
size of 256M on Solaris and I've seen a Java process use
600M...that means the VM itself is using at least 344M!

I'm having the same problem Sparc, Weblogic, plenty of SWAP

build 1.3.1_07-b02

SunOS us-sonicchill 5.8 Generic_108528-19

swap -s
total: 10242976k bytes allocated + 226848k reserved = 
10469824k used, 7121536k available


JAVA_OPTIONS="-server -native -Xnoclassgc -Xss1024k -
Xmx3072m -Xms3072m -XX:NewSize=2304m -
XX:MaxNewSize=2304m -XX:SurvivorRatio=2 -
XX:+DisableExplicitGC -verbose:gc -
Dweblogic.system.gc.enabled=false -XX:+UseISM"

I am having a problem loading documents into memory. I get 
the out of memory error even though I am using a measely 40 
MB on a 2 GB Memory with a 16GB swap that is mostly empty. 
I am working on a Sun System.

If anyone has a solution, please write to me at nmehra AT 
smi.stanford.edu

On Windows 2000 it's pretty easy to get an OutOfMemoryError
when physical memory is exceeded but swap space is not. 
Using -Xmx{physical memory < value << virtual memory}  seems
to get around this but that shouldn't be necessary.

We've encountered a very similar situation using both
1.3.1_08 and 1.4.1_02 on Win2K. We've fixed the heap size
with -Xms and -Xmx set to 1GB (4GB of RAM on the system),
however - we continue to see the same sorts of messages
"OutOfMemory - Requested XXX bytes" even though there is
space available on the heap. Looking at the output from
-verbose:GC we can see that this always occurs during a
FullGC (typically due to distributed garbage collection)...
our theory is that even with -Xms and -Xmx fixed to the same
value, internally the heap is reapportioned between Eden,
Survivor Spaces, Tenured Generation and Perm Generation
during a Full GC. We've gone as far as trying to pin
everything down with setting -XX:NewSize and -XX:MaxNewSize
and -XX:PermSize and -XX:MaxPermSize which has made a
difference in the frequency of the VM crashes, but we still
encounter this every 4-10 days.

I Used JavaWebStart and set initial/max-heap-size for JVM, 
but it was effected.
If I set initial-heap-size larger than 64M than JWS cannot 
start-up.
My application always throw OutOfMemory when the amount 
of data larger than 64MB, event when I set max-heap-
size=512m.
My application run on PC PIV 2.4 & DDRAM = 1GB and didnot 
run any other application else.

I have had the OutOfMemoryError  with weblogic 7.0 sp4 and
JDK 1.3.103, JDK1.3.108 and JDK1.3.109 when it tries  to
deploy  my ejb jar file.

 But when I step back to sp2 and Jdk1.3.106, the deployement
goes fine.  Just wanted to let  this workaround be known.

Regards
Rajesh J

We are getting the same OutOfMemory error in Tomcat 
4.0.6.   Memory for the java process increases to 
around 1 GB and then everything stops.  Heap max set 
to 512 MB.  This has showed up during load testing.

Configuration:
Tomcat 4.0.6, JDK 1.4.1_01, 4 GB RAM, Win2k Server
(SP4).

Another system with 1/4 the RAM does not exhibit this 
behaviour using Win2k(SP2).

The same problem exists on Red Advance server 3.0,J2SDK 1.4.2.05,Tomcat 5.0.27.Hardware: Dell 2650/2G memory and 2G swap memory.

On load test,this problem exist:

Exception in thread "ContainerBackgroundProcessor[StandardEngine[Catalina]]" jav
a.lang.OutOfMemoryError: requested 144 bytes for CHeapObj-new. Out of swap space?.

and then tomcat clean shutdown.

Anyone can help me ?

how increment swap size in solaris 9 and how much?
my machine is SUNFIRE V880 ultrasparc III.

laesquivel@ing-coam.com.mx
superesquivel@yahoo.com.mx

We are encountering this problem every day or so using WebLogic 8.1, SP2.  -mx and -ms are set to the same value, so it has nothing do do with growing the heap.   There is plenty of swap space and should be plenty of heap as well.  The characterization of the problem in the Evaluation and Workaround sections of this report seem to ignore the fact that heap growth and swap space seem to have nothing to do with the problem.  This problem needs to be re-evaluated based upon the new information in these notes.

I am getting this problem with the CMS garbage collector in jdk 1.4.2_05 on Solaris 8. I am using the following jvm switches:

  -server \
  -Xms${4}m \
  -Xmx${5}m \
  -XX:NewSize=`expr ${4} / 4`m \
  -XX:+UseParNewGC \
  -XX:ParallelGCThreads=6 \
  -XX:SurvivorRatio=32 \
  -XX:+UseConcMarkSweepGC \
  -XX:CMSInitiatingOccupancyFraction=80 \
  -XX:+CMSParallelRemarkEnabled \
  -XX:NewRatio=2 \
  -Dsun.rmi.dgc.client.gcInterval=3600000 \
  -Dsun.rmi.dgc.server.gcInterval=3600000 \
  -verbose:gc \
  -Xloggc:$GCLOGFILE \
  -XX:+PrintGCTimeStamps \
  -XX:+PrintGCDetails

The JVM fails with message:
"Exception java.lang.OutOfMemoryError: requested 4 bytes for CMS: Work queue overflow; try -XX:-CMSParallelRemarkEnabled. Out of swap space?"

Changing to 
  -XX:-CMSParallelRemarkEnabled
makes the problem go away.

I would like a fix which at least make the parallel remark of CMS safe to use.

Could you change the implementation to use data structures of a fixed size, pre-allocated so that errors just send you back to a known state?  It would be slightly less efficient, but easier to test, maintain and debug, plus it would allow you to go back to a known state.  Maybe the app can fee some data, if we could just throw a nice exception.

Regarding the comment about using pre-allocated fixed size data structures to avoid the problem of the JVM not being able to get additional memory during a garbage collection, the garbage collector does use pre-allocated data structures.  However, there are data structures that may need space that is proportional to the amount of live data in the heap.  It is very unusual that this actually occurs so space is not pre-allocated for this contingency (because such pre-allocated space would not be available to the application). Rather a fixed amount of space is pre-allocated and more is requested only in the rare situations where it is actually needed.  Also there are a  few situations where the JVM has requested that the operating system reserve space for the JVM and when the space is actually needed, it is not available.  Gracefully recovering from these situations is not always easy but we're trying.

How about simply releasing the jvm memory consumed and returning to a fresh state so it can continue servicing new calls and throw a error for existing processes that were consuming memory.

I have the heap set to 768M & 1024M on a system with 2GB RAM and 2GB swap and I still get the OOM error. With the limited number of users on that system we should *never* come close to consuming that much memory but somehow it does and subsequently the apps just hang and the phone calls start to flow.

Regarding the comment from MLPOKNBHUYGV, if I understand correctly, you are asking if an out-of-memory can be sent only to the thread that is consuming memory and resulted in the JVM calling vm_exit_out_of_memory().  As relates to 4697804 the JVM is trying to get memory so that it can complete a garbage collection.  As such there is no free space in the Java heap so that any request for the allocation of an object from any thread would fail. The JVM could release all its ancillary data structures but that doesn't change  the fact that the Java heap needs to be collected.  

If you are running into 4697804 the JVM would exit (i.e., applications would not simply hang).  It it looks like applications are hanging, the JVM may be continuously doing garbage collections but not recovering much free space so another garbage collection starts very soon.  Have you turned on -verbosegc to see what the level of gc activity is?  Even better would be -XX:+PrintGCDetails and -XX:+PrintGCTimeStamps to get more information about the garbage collections and to get time stamps on when the garbage collections occurred. 

I get this bug often when running Borland's Optimizeit with memory profiling on WebLogic 8.1+SP4. I don't think this bug is related to the amount of heap memory or swap space. These are the last four lines of my server log:

775096.571: [Full GC 775096.571: [Tenured: 75347K->75347K(483968K), 1.7098650 secs] 111635K->75347K(520256K), [Perm : 64915K->64915K(65024K)], 2.0344175 secs]
775158.624: [Full GC 775158.625: [Tenured: 76951K->76951K(483968K), 1.8080917 secs] 113239K->76951K(520256K), [Perm : 64915K->64915K(65024K)], 2.1579350 secs]

Exception java.lang.OutOfMemoryError: requested 30 757 680 bytes for unsigned char in D:/BUILD_AREA/jdk142-update/ws/fcs/hotspot\src\share\vm\prims\jvmpi.cpp. Out of swap space?

The JVM:
java version "1.4.2_08"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_08-b03)
Java HotSpot(TM) Client VM (build 1.4.2_08-b03, mixed mode)

My platform is Windows 2003 on 4x1.4GHz Intel XEON. Interestingly I've never seem this bug on my Solaris 9 (4x SPARC 9 CPUs) with the same setup.

Hi,

We use Resin 2.1.6 Web server to host our integration product. The product performs XSLT transformations to generate Object XML files. The problem that we face today is that when XSLT is applied to input XML file to generate output XML file, Resin stops and restarts abruptly. This happens only when the output XML files are too large in size. Resin throws an OutOfMemory Exception when ever large number of XML files have to be generated one after another.

A workaround that is followed is to reset JVM memory using -Xss -Xmm options at the command prompt. Though the problem is addressed temporarily it creeps up after few hours when output XML files are huge in size.

We have even tried increasing system RAM to 4GB but it does not help.

Please advice on how the problem can be resolved permanently. Do we need any patch or is this issue addressed in later releases of Java?

How large a value do you use with -Xmx and how much live data does your application require?  You can use the command line flag -XX:+PrintGCDetails to see how full the heap is after each garbage collection.  The documents under the following url explain how to read the output from -XX:+PrintGCDetails

http://java.sun.com/docs/hotspot/

Also you may find this url useful in asking
questions.

http://java.sun.com/docs/forms/gc-sendusmail.html

We were getting lots of 
java.lang.OutOfMemoryError: requested 12 bytes for CHeapObj-new. Out of swap space?
but the upgrade to 1.4.2 patch 11 removed all of them for us. (on win)