MemoryOutOfError in jvm native heap

hi,
i am getting MemoryOutOfError at JVM native heap.
anybody tell me why this is coming ?
thanks
Rams

You need be more specific about your phenomenon.
For example:
OS Info
JVM Info
JVM Options
Full Error Message
GC Dump
There are many possible reasons for OOEM in native heap.
Thread stack size, JNI library, virtual memory space(somtimes by too big java heap size), file/socket open count, ...
Even highly-specialized expert might not be able to tell which one is the main reason without more detailed information.
Anyway, JVM forum might be more appropriate place for your question.

Similar Messages

  • How to find out what is using the native heap of a process running a JVM?

    Hello,
    I am not sure where to post this question so I am starting here.
    I am troubleshooting a Java application using some native calls (32 bits Java running on Solaris 10). The size of the process (as reported by prstat) is slowly increasing day after day.
    The size of the 'Java heap' is fixed at the start (-Xms and -Xmx are set to the same value on the command line when launching the Java app) and the GC is workling fine. No memory complaints from the Java side of the application.
    It is the size of the 'native' heap (as reported by 'pmap') that is increasing:
    root@mas01 # pmap 5382
    5382:/apps/java/bin/java -server -Xms207M -Xmx207M -XX:MaxNewSize=24M -XX:N
    00010000 64K r-x-- /apps/jdk1.5.0_19/bin/java
    0002E000 16K rwx-- /apps/jdk1.5.0_19/bin/java
    00032000 3896K rwx-- [ heap ]
    00400000 389120K rwx-- [ heap ]
    18000000 2784K rwx-- [ heap ]
    DCAF4000 48K rw--R [ stack tid=169 ]
    DCBF6000 40K rw--R [ stack tid=161 ]
    DCCF8000 32K rw--R [ stack tid=160 ]
    My first reaction was to search for a memory leak. Found a minor leak in the JVM with the ::findleak function (called within the mdb debugger). Upgraded to a later release of Java 5 (Java 1.5.0_19) where the leak is fixed but the heap is still increasing.
    Many parts of the process allocate memory in the native heap. The JVM itself, the native calls made to a C++ library part of our Java application and maybe also some 3rd party software.
    I would like to know what is the best way to find out what is consuming more and more memory in the native heap. I started looking a DTraces but I am new to this. I also thought maybe the Solaris Perftools might be of use but I never used them. Before plunging into a tool more or less blindly, I am asking for advices on how to tackle this issue. Can someone recommend a tool/method to see what is allocated in the heap?
    Regards,
    Stéphan
    Edited by: StephanDupont on Sep 22, 2009 8:47 AM

    After googling a lot I managed to run my application with libumem, generated a core file and succeeded to find some leak with mdb even if ::findleak reported nothing.
    Does anyone knows if the ::findleak (you need libumem and mdb) is supposed to find leak in the native part of the memory and a Java application using the JNI interface?
    Regards,
    Stéphan

  • OutOfMemoryError in native heap ?

    hi,
    we are getting OutOfMemoryError in native heap.
    till now we are not getting why this is happening.
    my application is running on solaris 8 and jvm is 1.4.2,
    i am not seeing any profiling tool to find this issue for this environment.
    anybody used any profiling tool for solaris 8 and jvm 1.4.2
    plz suggest me.
    that will help to sort out my problem.
    thanks
    rams

    What's the exact message you are seeing?
    Try the tips in the Trouble-Shooting Guide:-
    http://java.sun.com/javase/6/webnotes/trouble/TSG-VM/html/toc.html
    in particular this section:-
    http://java.sun.com/javase/6/webnotes/trouble/TSG-VM/html/memleaks.html

  • Native heap exaustion under Linux 2.6.x

    All,
    We have an application that extensively uses Runtime.exec() in a multi-threaded
    environment. Under both JRockit 1.4.2_8 and 1.4.2_10 x86 we observe steady growth
    of resident and virtual memory occupied by JVM, as reported by top, that eventually
    leads to the death of JVM.
    Java heap behaves normally. The application that is repeatedly executed by Runtime.exec()
    doesn't leak. That was confirmed by running it in a bash cycle.
    I am wondering if this is a known problem and if there is a fix or a workaround
    for this issue. If not, what are the ways to track down the problem?
    Thanks.
    Slava

    Calling deleteOnExit() on a File adds that file to a list of files that the JVM should delete once it exits. Files are never
    removed from this list. Thus, if you keep adding files to the list (by calling deleteOnExit()) you will run out of memory
    eventually.That may be what the JVM code does. Here is what the documentation says:
    ================================================================
    deleteOnExit
    public void deleteOnExit()
    Requests that the file or directory denoted by this abstract pathname be deleted when the
    virtual machine terminates. Deletion will be attempted only for normal termination of the virtual
    machine, as defined by the Java Language Specification.
    Once deletion has been requested, it is not possible to cancel the request. This method
    should therefore be used with care.
    Note: this method should not be used for file-locking, as the resulting protocol cannot
    be made to work reliably. The FileLock facility should be used instead.
    Throws:
    SecurityException - If a security manager exists and its SecurityManager.checkDelete(java.lang.String)
    method denies delete access to the file
    Since:
    1.2
    See Also:
    delete()"
    ================================================================
    As you can see, there is nothing in here that would alert that either there is
    a list that may cause *native heap* overflow nor that actual deletions of the
    file don't remove a file from the list. For all practical reasons it is a bug that
    was lurking there since 2001:
    http://bugs.sun.com/bugdatabase/view_bug.do;:YfiG?bug_id=4513817
    Other JVM vendors such as IBM have taken care about this problem (see #97403):
    http://www-1.ibm.com/support/docview.wss?uid=swg21221304
    It would be nice if you guys looked at this issue.
    Apart from that I am very pleased with JRockIt speed and improved stability - good
    job!
    Regards,
    Slava Imeshev

  • JVMDG315: JVM Requesting Heap dump file

    Hi expert,
    Using 10.2.04 Db with 11.5.10.2 on AIX 64 bit.
    While running audit report which generate pdf format output gone in error....
    JVMDG217: Dump Handler is Processing OutOfMemory - Please Wait.
    JVMDG315: JVM Requesting Heap dump file
    ..............................JVMDG318: Heap dump file written to /d04_testdbx/appltop/testcomn/admin/log/TEST_tajorn3/heapdump7545250.1301289300.phd
    JVMDG303: JVM Requesting Java core file
    JVMDG304: Java core file written to /d04_testdbx/appltop/testcomn/admin/log/TEST_tajorn3/javacore7545250.1301289344.txt
    JVMDG274: Dump Handler has Processed OutOfMemory.
    JVMST109: Insufficient space in Javaheap to satisfy allocation request
    Exception in thread "main" java.lang.OutOfMemoryError
         at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java(Compiled Code))
         at java.io.OutputStream.write(OutputStream.java(Compiled Code))
         at oracle.apps.xdo.common.log.LogOutputStream.write(LogOutputStream.java(Compiled Code))
         at oracle.apps.xdo.generator.pdf.PDFStream.output(PDFStream.java(Compiled Code))
         at oracle.apps.xdo.generator.pdf.PDFGenerator$ObjectManager.write(PDFGenerator.java(Compiled Code))
         at oracle.apps.xdo.generator.pdf.PDFGenerator$ObjectManager.writeWritable(PDFGenerator.java(Inlined Compiled Code))
         at oracle.apps.xdo.generator.pdf.PDFGenerator.closePage(PDFGenerator.java(Compiled Code))
         at oracle.apps.xdo.generator.pdf.PDFGenerator.newPage(PDFGenerator.java(Compiled Code))
         at oracle.apps.xdo.generator.ProxyGenerator.genNewPageWithSize(ProxyGenerator.java(Compiled Code))
         at oracle.apps.xdo.generator.ProxyGenerator.processCommand(ProxyGenerator.java(Compiled Code))
         at oracle.apps.xdo.generator.ProxyGenerator.processCommandsFromDataStream(ProxyGenerator.java(Compiled Code))
         at oracle.apps.xdo.generator.ProxyGenerator.close(ProxyGenerator.java:1230)
         at oracle.apps.xdo.template.fo.FOProcessingEngine.process(FOProcessingEngine.java:336)
         at oracle.apps.xdo.template.FOProcessor.generate(FOProcessor.java:1043)
         at oracle.apps.xdo.oa.schema.server.TemplateHelper.runProcessTemplate(TemplateHelper.java:5888)
         at oracle.apps.xdo.oa.schema.server.TemplateHelper.processTemplate(TemplateHelper.java:3593)
         at oracle.apps.pay.pdfgen.server.PayPDFGen.processForm(PayPDFGen.java:243)
         at oracle.apps.pay.pdfgen.server.PayPDFGen.runProgram(PayPDFGen.java:795)
         at oracle.apps.fnd.cp.request.Run.main(Run.java:161)
    oracle.apps.pay.pdfgen.server.PayPDFGen
    Program exited with status 1
    No any error in db alert ...
    Pleaes suggest where is prob..
    Thanks in ADV

    Hello,
    * JVMST109: Insufficient space in Javaheap to satisfy allocation request
    Exception in thread "main" java.lang.OutOfMemoryError
    This is your problem. There is no enough memory. Change Java heap settings
    Regards,
    Shomoos
    Edited by: shomoos.aldujaily on Mar 29, 2011 12:39 AM

  • Advanced: JVM native methods

    Please note: this topic has nothing to do with JNI or reflection.
    In the java.lang.Throwable class there is:
    private native StackTraceElement getStackTraceElement(int index);
    The simplest solution to Java Bug 6349551 is to change this method from private to public. I'm prepared to contribute this change to Mustang.
    However, I'm looking for peer input first as I can't find a lot of information about JVM native methods.
    My question is: Are there good reasons to avoid directly exposing JVM native methods? I'm most interested in this specific case, but would also like to learn more about the issues in general.
    Also, my bug posting includes an alternative approach which wraps getStackTraceElement() instead. Is that a better approach, and if so, why?

    See my comment in bug database.

  • Sudden increase in native heap memory

    Hi all,
    we are using JRockit 26.4 and currently configured with 1800MB heap on windows 2003 with /3GB switch.
    We noticed that after the weblogic server is started the total memory (java heap + native memory) lingers around 2550 MB... (We monitored this using perfmon -> virtual bytes of java process)
    after couple of days run, the native memory suddenly increased by 300 MB, taking the total virtual bytes to 2850 MB.
    Do we know what could be the reason for such a sudden increase?
    Thanks,
    - Pritam.

    I don't believe this is documented anywhere unfortunately, and it might vary depending on the exact JRockit release. But the key thing to watch out for is growth, regardless of which component it is. If you see that, post a question here and we'll find someone to tell you what the issue is...
    That said, here's an example printout and some guesses from my side.
    [JRockit] memtrace is collecting data...
    [JRockit] *** 0th memory utilization report
    (all numbers are in kbytes)
    Total mapped                         ;;;;;;; 860976
    ; Total in-use                        ;;;;;;  89816
    ;;  executable                         ;;;;;   4400
    ;;;   java code                         ;;;;    384;   8.7%
    ;;;;    used                             ;;;    236;   61.6%
    ;;  shared modules (exec+ro+rw)        ;;;;;   8496
    ;;  guards                             ;;;;;    180
    ;;  readonly                           ;;;;;   3052
    ;;  rw-memory                          ;;;;;  78132
    ;;;   Java-heap                         ;;;;  65536;   83.9%
    ;;;   Stacks                            ;;;;   1976;   2.5%
    ;;;   Native-memory                     ;;;;  10619;   13.6%
    ;;;;    java-heap-overhead               ;;;   2056
    ;;;;    codegen memory                   ;;;    576
    ;;;;    classes                          ;;;   2048;   19.3%
    ;;;;;     method bytecode                 ;;    219
    ;;;;;     method structs                  ;;    277    (#5929)
    ;;;;;     constantpool                    ;;    788
    ;;;;;     classblock                      ;;     69
    ;;;;;     class                           ;;    143    (#443)
    ;;;;;     other classdata                 ;;    338
    ;;;;;     overhead                        ;;     91
    ;;;;    threads                          ;;;      6;   0.1%
    ;;;;    malloc:ed memory                 ;;;   1445;   13.6%
    ;;;;;     codeinfo                        ;;     60
    ;;;;;     codeinfotrees                   ;;     24
    ;;;;;     exceptiontables                 ;;      5
    ;;;;;     metainfo/livemaptable           ;;    243
    ;;;;;     codeblock structs               ;;      0
    ;;;;;     constants                       ;;      0
    ;;;;;     livemap global tables           ;;    135
    ;;;;;     callprof cache                  ;;      0
    ;;;;;     paraminfo                       ;;     30    (#506)
    ;;;;;     strings                         ;;    426    (#8402)
    ;;;;;     strings(jstring)                ;;      0
    ;;;;;     typegraph                       ;;     27
    ;;;;;     interface implementor list      ;;      5
    ;;;;;     thread contexts                 ;;      8
    ;;;;;     jar/zip memory                  ;;    497
    ;;;;;     native handle memory            ;;      5
    ;;;;    unaccounted for memory           ;;;   4493;   42.3%;3.11
    ---------------------!!!Total mapped means mapped virtual memory, eg the largest size the JVM can be expected to grow to. This is typically on the same order of magnitude as the Java heap size (Xmx).
    Total in-use is the actual memory in use, this is the current "memory footprint" of your process.
    executable refers to JIT compiled code, I believe.
    Java-heap is the heap (duh).
    Stacks should be the thread stacks (where local variables are stored).
    classes is native memory used to store bytecode etc. If this grows, it may be because you are generating classes dynamically and they are not getting cleaned up because there are still live instances. Or maybe you're running with -Xnoclassgc.
    threads can grow if you start a lot of threads and don't let them die.
    Stuff under malloc:ed memory is mainly misc JVM metadata.
    unaccounted for memory is...everything else. The most common leak involving unaccounted-for is native byte buffers (DirectByteBuffer).
    -- Henrik

  • DPS 6.x jvm memory heap size?

    I am setting up directory proxy server 6.3 and have the java setting for memory heap size in my notes from testing last year. Is it important to set this? Is the argument as stated ok? And is 500 ok? Doubt anything has changed since last year, but want to be sure. Thanks.
    dpadm set-flags /opt/dps jvm-args="-Xmx500M -Xms500M -XX:NewRatio=1"

    crosspost

  • JVM Java heap space Error || even with -Xms- and -Xmx commands

    hi all, i got a problem by allocating a very great boolean array.
    first of all, here is my testcode:
    public static void main(String[] args) {
              boolean[] testfield = new boolean[70000000];          
              while(true){
              //NOP     
         }as you see, i try to allocate an array with 70.000.000 boolean values - as 1 boolean may be represented as at least one physical bit we calculate the total amount of needed RAM-Space:
    70.000.000 bit / 8 = 8750000 byte
    8.750.000 byte = 8.75 MByte
    My System ist WinVista Ultimate 64-bit running on a Quadcore T2200 with 2GB-DDR3 RAM
    Looking in my Vista Ressourcemanager shows, that eclipse.exe reserves about 1.023 Mbyte....
    As IDE I use eclipse
    my eclipse.ini looks as follows:
    -showsplash
    org.eclipse.platform
    --launcher.XXMaxPermSize
    256M
    -vmargs
    -Dosgi.requiredJavaVersion=1.5
    -Xms512m
    -Xmx1024m
    -XX:PermSize=512mby using following VMCommand "-XX:+PrintGCDetails" and running the above code the output displays:
    [GC [DefNew: 180K->63K(960K), 0.0008311 secs][Tenured: 43K->107K(4096K), 0.0060371 secs] 180K->107K(5056K), 0.0069249 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]
    [Full GC [Tenured: 107K->105K(60544K), 0.0044835 secs] 107K->105K(61504K), [Perm : 17K->16K(12288K)], 0.0045553 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
    Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
         at termain.main(termain.java:15)
    Heap
    def new generation   total 4544K, used 163K [0x246a0000, 0x24b80000, 0x24b80000)
      eden space 4096K,   4% used [0x246a0000, 0x246c8fe0, 0x24aa0000)
      from space 448K,   0% used [0x24aa0000, 0x24aa0000, 0x24b10000)
      to   space 448K,   0% used [0x24b10000, 0x24b10000, 0x24b80000)
    tenured generation   total 60544K, used 105K [0x24b80000, 0x286a0000, 0x286a0000)
       the space 60544K,   0% used [0x24b80000, 0x24b9a420, 0x24b9a600, 0x286a0000)
    compacting perm gen  total 12288K, used 16K [0x286a0000, 0x292a0000, 0x2c6a0000)
       the space 12288K,   0% used [0x286a0000, 0x286a41c0, 0x286a4200, 0x292a0000)
        ro space 8192K,  62% used [0x2c6a0000, 0x2cba2ba0, 0x2cba2c00, 0x2cea0000)
        rw space 12288K,  52% used [0x2cea0000, 0x2d4e88e0, 0x2d4e8a00, 0x2daa0000)so can anyone tell me please, how i manage to allocate bigger arrays? or where at least is the problem?
    Originally i was thinking like that way: Integer.MAXVALUE = (2^32)-1
    => biggest index an array can have
    => biggest allocation possible with ints weights (((2^32)-^1)/8)/1000*1000 = (round) 537 MByte < 2GByte => everything fine .... but it seems like not :-(
    When i try to allocate 60.0000.000 it works fine....but that is far not enough :-&
    thank you very much for your helping answers!

    The Sun Java virtual machine stores booleans as bytes, not bits, so for an array of 70 million booleans you need 70 million bytes, plus 8 bytes for the object header, and 4 bytes for the array length.
    I suspect that your eclipse.ini controls the JVM running the Eclipse IDE, not the JVM running your application. Note that in the -XX:+PrintGCDetails output at the end, it shows you running out of memory with 4MB of young generation and 60MB of old generation. That's the default configuration, as if you hadn't specified -Xms and -Xmx.
    The array of 60 million booleans only requires 60 million bytes (plus overhead), which fits in the default old generation.
    I think you need to put the -Xms and -Xmx in the same place you put the -XX:+PrintGCDetails, since that does seem to display information about the JVM running your application, not the JVM running Eclipse.

  • JVM OutOfMemory Heap Suddenly Rises

    Hi,
    Can anyone help me step by step to solve the Out Of Memory Issue we are facing in our application.
    After the restart the JVM runs perfectly fine for first 2 days ,the heap stablizes at 50%,but from 3rd day onward it starts shooting up and by 4th day it goes OOM.Earlier it was stable for 4 days and then 5th day it goes OOM and now it has become worse.
    I am wondering if its really a memory leak in my applicaiton or the following possibilities
    -fragmentation
    -cache overflow
    -inefficient garbage collection
    Also i have noticed that the rate of full GC increases sharply after 2 days .I would be glad if someone could guide me step by step to find the root cause and solve the problem as i belive most of you here are the experts.
    Our application run on websphere 6 ,max heap 1g ,min heap 1g,default garbage collection.
    Thanks,
    DammieeNew

    Also i forgot to mention we have 8jvms on two servers..
    If i take one snapshot for 3 days using jstat this is wat i see ...
    Day1 heap 51.87% FullGC 94
    Day2 heap 51.37% FullGC 265
    Day3 heap 94.34 FullGC 1758 (See the increase in heap ..)
    I am not an expert in this matter so my questions will be basic and plain.Please tolerate with me.Thanks!!

  • Monitoring JVM Heap

    I would like to be able to see what happened to the JVM's heap following a
    performance test.
    I'm really only interested in amount of heap used (ideally for each area of
    the heap - in 1.3 onwards). If I could get this figure regularly (say every
    5 seconds) I would be able to plot and see from the graph whether I have too
    little or too much heap.
    Is verbosegc the best way to do this i.e. just get the figures either side
    of a gc? Or is there a better way? I don't want a GUI tool as the runs can
    take hours and I want to be able to sleep! Just something that outputs to a
    file.
    Thanks in advance for all advice
    Ed

    "Ed Barrett" <[email protected]> wrote:
    I would like to be able to see what happened to the JVM's heap following
    a
    performance test.
    I'm really only interested in amount of heap used (ideally for each area
    of
    the heap - in 1.3 onwards). If I could get this figure regularly (say
    every
    5 seconds) I would be able to plot and see from the graph whether I have
    too
    little or too much heap.
    Is verbosegc the best way to do this i.e. just get the figures either
    side
    of a gc? Or is there a better way? I don't want a GUI tool as the runs
    can
    take hours and I want to be able to sleep! Just something that outputs
    to a
    file.
    Thanks in advance for all advice
    Ed
    Verbosegc is a good option. Here is how you can do it. Set the heap size to one
    of your lower settings. Turn on verbosegc. See how frequently you collect GC.
    If you never do it then you do not use a high amount of memory. If the GC is too
    frequent then your heap size is small.

  • What would make a JVM memory size 1.9GB ?

    This is on Solaris 2.6, JDK 1.2.2_05a, JDK1.2.2_07, possibly JDK 1.3 (it crashed).
    WLS 5.1, SP8. With inline_instrs_jit=0.
    This is the [heap] segment shown by /usr/proc/bin/pmap. This is native heap, it is
    NOT the Java Heap.
    I know it could be the Type 2 db drivers - but I doubt it.
    With JDK1.3 we set -XX:MaxPermSize=128m - it crashes after an hour.
    One part of the application creates its own threads for some parallel processing.
    Is this a known
    problem with the JVMs?
    Any help is much appreciated.
    Mike Reiche

    What is the 'Break difference' that the debug JVM shows? Is that the Java Heap? Or
    is memory in the C Heap that is wasted by fragmentation?
    ============== C Heap Report ========================
    mmap space 300515328
    Committed space 95690752
    Allocated space 34049316
    Break difference 66060288
    Breakdown by type:
    ClassSpace 15252128
    JITCompiledStackMaps 5277188
    StackMap 1892672
    Dependency 1856760
    utf8_space 1854838
    untagged 1783520
    basicBlocksState 1664992
    utf8_table 1055903
    Class 811520
    JITPrestub 610480
    NearClass 531360
    CardObjectTable 386048
    JavaStack 257024
    CheckingDone 200367
    SummaryCardTable 193024
    name_loader_cache_entry 65976
    ScratchRecord 65548
    basic_block_t 50896
    IntfMethodTable 48960
    stringTableOverflowRecord 46480
    BitVectorElem 32768
    ObjectMap 30724
    ClassName 28407
    Clinit 18752
    Table_mem 18628
    LoaderConstraintsTableEntry 11668
    JITInlineByteCode 1928
    LoaderConstraintsTableLoaderEntry 520
    stateVecBuf 237
    =====================================================
    Total GC time: 2987981 ms
    - Mike
    "[email protected]" Mike wrote:
    >
    >
    Aslo - GC[1] are taking way long (Debug JVM) - I'm used to seeing them taking
    500
    ms with the regular JVM. With -ms32m -m256m - I wanted GC[1] to run often
    because
    that has helped with other memory problems in the past - it doesn't work
    so hot here.
    GC[1] in 5514 ms: (38Mb, 0% free) -> (38Mb, 69% free)
    GC[1] in 6300 ms: (38Mb, 0% free) -> (38Mb, 65% free)
    GC[1] in 7130 ms: (38Mb, 0% free) -> (38Mb, 64% free)
    GC[1] in 6158 ms: (38Mb, 2% free) -> (38Mb, 62% free)
    GC[1] in 6171 ms: (38Mb, 0% free) -> (38Mb, 65% free)
    GC[1] in 6885 ms: (38Mb, 0% free) -> (38Mb, 64% free)
    GC[1] in 7403 ms: (38Mb, 0% free) -> (38Mb, 61% free)
    GC[1] in 689101:25:49 PM PST {218} - Evaluation is: true
    GC[1] in 6545 ms: (38Mb, 1% free) -> (38Mb, 61% free)
    GC[1] in 7459 ms: (38Mb, 0% free) -> (38Mb, 62% free)
    GC[1] in 6861 ms: (38Mb, 2% free) -> (38Mb, 58% free)
    GC[1] in 6090 ms: (38Mb, 0% free) -> (38Mb, 56% free)
    GC[1] in 6413 ms: (38Mb, 0% free) -> (38Mb, 60% free)
    GC[1] in 8230 ms: (38Mb, 1% free) -> (38Mb, 58% free)
    GC[1] in 7649 ms: (38Mb, 0% free) -> (38Mb, 54% free)
    GC[1] in 7912 ms: (38Mb, 0% free) -> (38Mb, 55% free)
    GC[1] in 7696 ms: (38Mb, 1% free) -> (38Mb, 57% free)
    GC[1] in 6543 ms: (38Mb, 1% free) -> (38Mb, 60% free)
    GC[1] in 7036 ms: (38Mb, 1% free) -> (38Mb, 59% free)
    GC[1] in 7483 ms: (38Mb, 0% free) -> (38Mb, 56% free)
    GC[1] in 5132 ms: (38Mb, 1% free) -> (38Mb, 59% free)
    GC[1] in 8186 ms: (38Mb, 0% free) -> (38Mb, 53% free)
    GC[1] in 5691 ms: (38Mb, 0% free) -> (38Mb, 58% free)
    GC[1]01:35:49 PM PST {575} - Evaluation is: true
    GC[1] in 8176 ms: (38Mb, 0% free) -> (38Mb, 46% free)
    GC[1] in 8463 ms: (38Mb, 0% free) -> (38Mb, 47% free)
    GC[1] in 7342 ms: (38Mb, 0% free) -> (42Mb, 41% free)
    GC[1] in 6920 ms: (42Mb, 0% free) -> (49Mb, 41% free)
    GC[1] in 8610 ms: (49Mb, 1% free) -> (60Mb, 40% free)
    GC[1] in 9581 ms: (60Mb, 1% free) -> (60Mb, 50% free)
    GC[1] in 10514 ms: (60Mb, 0% free) -> (60Mb, 59% free)
    GC[1] in 9865 ms: (60Mb, 0% free) -> (60Mb, 60% free)
    GC[1] in 11323 ms: (60Mb, 0% free) -> (60Mb, 57% free)
    GC[1] in 18768 ms: (60Mb, 0% free) -> (60Mb, 60% free)
    GC[1] in 11147 ms: (60Mb, 0% free) -> (60Mb, 55% free)
    GC[1] in 7293 ms: (60Mb, 0% free) -> (60Mb, 42% free)
    GC[1] in 9372 ms: (60Mb, 0% free) -> (60Mb, 53% free)
    GC[1] in 8814 ms: (60Mb, 0% free) -> (60Mb, 55% free)
    GC[1] in 9695 ms: (60Mb, 1% free) -> (60Mb, 54% free)
    GC[1] in 7309 ms: (60Mb, 0% free) -> (60Mb, 53% free)
    GC[1] in 8713 ms: (60Mb, 0% free) -> (60Mb, 54% free)
    GC[1] in 11955 ms: (60Mb, 0% free) -> (60Mb, 55% free)
    GC[1] in 12685 ms: (60Mb, 1% free) -> (60Mb, 55% free)
    GC[1] in 18906 ms: (60Mb, 0% free) -> (60Mb, 58% free)
    GC[1] in 13333 ms: (60Mb, 0% free) -> (60Mb, 51% free)
    "[email protected]" <[email protected]> wrote:
    Rob -
    Thanks for your attention -
    We create lots of threads - up to five threads for each DB hit (i didn't
    design it).
    The multi-threading will be disabled/removed and tested later on today.
    Both 'top'
    and pstack show around 85 threads.
    I've read articles on the bea newsgroups about WL hanging on to threadreferences
    so that the threads could not be GC'ed, but it sounded more like a customer's
    impression
    of what might be going on than something from BEA engineering.
    Right now we are running with the 1.2.2_05a 'Debug' JVM with -verbose:gc
    -verbose:gc
    -verbose:gc
    JVMARGS=verbose_c_heap,inline_instrs_jit=0
    Unfortunately, some of the code being tested is now broken and not being
    excercised
    today. I will keep you posted.
    - Mike
    Rob Woollen <[email protected]> wrote:
    How many threads are you creating?
    Each thread uses some memory (stack etc.), but 1.9GB would be a lot of
    thread creation.
    -- Rob
    Mike Reiche wrote:
    This is on Solaris 2.6, JDK 1.2.2_05a, JDK1.2.2_07, possibly JDK 1.3
    (it
    crashed).
    WLS 5.1, SP8. With inline_instrs_jit=0.
    This is the [heap] segment shown by /usr/proc/bin/pmap. This is nativeheap, it is
    NOT the Java Heap.
    I know it could be the Type 2 db drivers - but I doubt it.
    With JDK1.3 we set -XX:MaxPermSize=128m - it crashes after an hour.
    One part of the application creates its own threads for some parallelprocessing.
    Is this a known
    problem with the JVMs?
    Any help is much appreciated.
    Mike Reiche--
    Coming Soon: Building J2EE Applications & BEA WebLogic Server
    by Michael Girdley, Rob Woollen, and Sandra Emerson
    http://learnweblogic.com

  • Solaris JVM Process Growth

    Hi,
    I am investigating a problem where we experience continual growth of our JVM process. The overall process size and native heap size of the JVM process continually grow at the same rate. I am monitoring these using the commands 'ps - o pid,vsz,rss' and 'pmap -x' respectively. The increases are in multiples of 8Kb.
    I have checked our java application using Optimizeit and it is not leaking memory. I have also monitored the size of the VM java heap using the '-verbose:gc' garbage collection debugging option. Garbage collection appears normal and the VM heap size remains below that specified by the '-Xmx' option.
    It appears that the memory growth is occurring in native code of the JVM process but I am at a loss on how to determine what is causing this. Can anyone advise me what may be causing this JVM process growth or ways in which I may be able to find this out?
    I am using JRE 1.4.2 SE (1.4.2_08_b03) on Solaris 8. Within the JVM we are running our web app in Tomcat 4.1.
    The shared libraries loaded by the JVM (as shown by pldd) are:
    /usr/lib/libthread.so.1
    /usr/lib/libdl.so.1
    /usr/lib/libc.so.1
    /usr/platform/sun4u/lib/libc_psr.so.1
    /vob/ntg-thirdparty/java/j2sdk1.4.2_08/jre/lib/sparc/client/libjvm.so
    /usr/lib/libCrun.so.1
    /usr/lib/libsocket.so.1
    /usr/lib/libnsl.so.1
    /usr/lib/libm.so.1
    /usr/lib/libsched.so.1
    /usr/lib/libmp.so.2
    /vob/ntg-thirdparty/java/j2sdk1.4.2_08/jre/lib/sparc/native_threads/libhpi.so
    /vob/ntg-thirdparty/java/j2sdk1.4.2_08/jre/lib/sparc/libverify.so
    /vob/ntg-thirdparty/java/j2sdk1.4.2_08/jre/lib/sparc/libjava.so
    /vob/ntg-thirdparty/java/j2sdk1.4.2_08/jre/lib/sparc/libzip.so
    /vob/ntg-thirdparty/java/j2sdk1.4.2_08/jre/lib/sparc/libjdwp.so
    /vob/ntg-thirdparty/java/j2sdk1.4.2_08/jre/lib/sparc/libdt_socket.so
    /usr/lib/nss_files.so.1
    /vob/ntg-thirdparty/java/j2sdk1.4.2_08/jre/lib/sparc/libnet.so
    /vob/ntg-thirdparty/tibco/rv-7.1/sol28/lib/libtibrvj.so
    /vob/ntg-thirdparty/tibco/rv-7.1/sol28/lib/libtibrvcmq.so
    /vob/ntg-thirdparty/tibco/rv-7.1/sol28/lib/libtibrvcm.so
    /vob/ntg-thirdparty/tibco/rv-7.1/sol28/lib/libtibrvft.so
    /vob/ntg-thirdparty/tibco/rv-7.1/sol28/lib/libtibrv.so
    /usr/lib/libpthread.so.1
    /vob/ntg-thirdparty/java/j2sdk1.4.2_08/jre/lib/sparc/libnio.so
    /usr/lib/librt.so.1
    /usr/lib/libaio.so.1
    /usr/lib/libsendfile.so.1
    /vob/ntg/dev/resources/lib/sol8gcc/libjavaperljni.so
    /vob/ntg/dev/thirdparty/perl-5.8.0-gcc-thread/lib/libperl.so
    /usr/lib/libw.so.1
    /vob/ntg/dev/resources/lib/sol8gcc/libstdc++.so.2.10.0
    /vob/ntg-thirdparty/java/j2sdk1.4.2_08/jre/lib/sparc/libioser12.so
    /vob/ntg-thirdparty/java/j2sdk1.4.2_08/jre/lib/sparc/libawt.so
    /vob/ntg-thirdparty/java/j2sdk1.4.2_08/jre/lib/sparc/libmlib_image.so
    /vob/ntg-thirdparty/java/j2sdk1.4.2_08/jre/lib/sparc/headless/libmawt.so
    /vob/ntg-thirdparty/java/j2sdk1.4.2_08/jre/lib/sparc/libcmm.so
    /vob/ntg-thirdparty/java/j2sdk1.4.2_08/jre/lib/sparc/libfontmanager.so
    /vob/ntg-thirdparty/java/j2sdk1.4.2_08/jre/lib/sparc/libdcpr.so
    /vob/ntg-thirdparty/java/j2sdk1.4.2_08/jre/lib/sparc/libjpeg.so
    Any Help is much appreciated.

    Hi
    If u can, use 1.4.2_10 (latest as of now). There is a bug 6250517, fixed in _09. Not sure if u r making any calls to NetworkInterface.getNetworkInterfaces.
    Also noticed that you are using tibco. How about putting -Xcheck:jni and see if it picks up anything.
    Unfortunately Solaris 8 didnt have libumem for tracking memory allocation. If u have any Solaris 9/10 boxes, you can use libumem to track it down.
    http://access1.sun.com/techarticles/libumem.html

  • OPP JAVA HEAP Out of memory

    hi all
    ebs:11.5.10.2
    db:9i
    AIX 5 64-bit
    we have 5 target process and 4 actual process
    all the actual process are struck and one one is active
    and log file of one process out 3 struck is (other 2 logs are same)
    [6/20/11 9:12:44 PM] [15905:RT2458306] Starting XML Publisher post-processing action.
    [6/20/11 9:12:44 PM] [15905:RT2458306]
    Template code: XXXXXXXXXXXXX
    Template app: WSH
    Language: en
    Territory: 00
    Output type: PDF
    java.lang.OutOfMemoryError
         at oracle.ias.cache.DefaultCacheLogger.flushRecords(Unknown Source)
         at oracle.ias.cache.DefaultCacheLogger.flushBuffer(Unknown Source)
         at oracle.ias.cache.DefaultCacheLogger.flush(Unknown Source)
         at oracle.ias.cache.CacheCleaner.run(Unknown Source)
    java.lang.OutOfMemoryError
         at oracle.apps.fnd.cp.opp.OPPRequestThreadManager.checkThreads(OPPRequestThreadManager.java(Compiled Code))
    java.lang.OutOfMemoryError
         at oracle.jdbc.driver.LRUStatementCache.addToImplicitCache(LRUStatementCache.java(Compiled Code))
         at oracle.jdbc.driver.OracleConnection.cacheImplicitStatement(OracleConnection.java(Inlined Compiled Code))
         at oracle.jdbc.driver.OraclePreparedStatement.privateClose(OraclePreparedStatement.java(Compiled Code))
         at oracle.jdbc.driver.OraclePreparedStatement.close(OraclePreparedStatement.java(Compiled Code))
         at oracle.jdbc.driver.OracleCallableStatement.close(OracleCallableStatement.java(Compiled Code))
         at oracle.apps.fnd.cp.opp.OPPAQMonitor.waitForMessage(OPPAQMonitor.java(Compiled Code))
         at oracle.apps.fnd.cp.opp.OPPAQMonitor.run(OPPAQMonitor.java(Compiled Code))
         at java.lang.Thread.run(Thread.java:570)
    java.lang.OutOfMemoryError
    java.lang.OutOfMemoryError
    java.lang.OutOfMemoryError
         at oracle.apps.fnd.common.Pool.createObject(Pool.java(Compiled Code))
         at oracle.apps.fnd.common.Pool.createAvailableObject(Pool.java(Compiled Code))
         at oracle.apps.fnd.common.Pool.resize(Pool.java(Compiled Code))
         at oracle.apps.fnd.common.Pool.run(Pool.java(Compiled Code))
         at java.lang.Thread.run(Thread.java:570)
    Exception: java.lang.OutOfMemoryError
    java.lang.OutOfMemoryError
         at oracle.ias.cache.group.Sender.run(Unknown Source)
    java.lang.OutOfMemoryError
         at oracle.jdbc.dbaccess.DBDataSetImpl._allocItemsAndBuffers(DBDataSetImpl.java(Compiled Code))
         at oracle.jdbc.dbaccess.DBDataSetImpl._allocDataAndItems(DBDataSetImpl.java(Inlined Compiled Code))
         at oracle.jdbc.dbaccess.DBDataSetImpl.setType(DBDataSetImpl.java(Compiled Code))
         at oracle.jdbc.dbaccess.DBDataSetImpl.setType(DBDataSetImpl.java(Compiled Code))
         at oracle.jdbc.driver.OracleCallableStatement.registerOutParameterBytes(OracleCallableStatement.java(Compiled Code))
         at oracle.jdbc.driver.OracleCallableStatement.registerOutParameter(OracleCallableStatement.java(Inlined Compiled Code))
         at oracle.jdbc.driver.OracleCallableStatement.registerOutParameter(OracleCallableStatement.java(Compiled Code))
         at oracle.apps.fnd.cp.gsm.GenCartComm.getQueueMessage(GenCartComm.java:186)
         at oracle.apps.fnd.cp.gsf.GSMStateMonitor.waitForNextEvent(GSMStateMonitor.java:95)
         at oracle.apps.fnd.cp.gsf.GSMServiceController.mainLoop(GSMServiceController.java:236)
         at oracle.apps.fnd.cp.gsf.BaseServiceController.run(BaseServiceController.java:71)
         at java.lang.Thread.run(Thread.java:570)
    [6/20/11 9:59:51 PM] [UNEXPECTED] [15905:RT2458306] java.lang.reflect.InvocationTargetException
    Caused by: java.lang.OutOfMemoryError
         at oracle.xdo.parser.v2.XPathDescendantAxis.getNodeList(XPathAxis.java(Compiled Code))
         at oracle.xdo.parser.v2.XPathStep.evaluate(XPathStep.java(Compiled Code))
         at oracle.xdo.parser.v2.PathExpr.evaluate(XSLNodeSetExpr.java(Compiled Code))
         at oracle.xdo.parser.v2.XSLForEach.processAction(XSLForEach.java(Compiled Code))
         at oracle.xdo.parser.v2.XSLNode.processChildren(XSLNode.java(Compiled Code))
         at oracle.xdo.parser.v2.XSLResultElement.processAction(XSLResultElement.java(Compiled Code))
         at oracle.xdo.parser.v2.XSLNode.processChildren(XSLNode.java(Compiled Code))
         at oracle.xdo.parser.v2.XSLTemplate.processAction(XSLTemplate.java:191)
         at oracle.xdo.parser.v2.XSLStylesheet.execute(XSLStylesheet.java:508)
         at oracle.xdo.parser.v2.XSLStylesheet.execute(XSLStylesheet.java:485)
         at oracle.xdo.parser.v2.XSLProcessor.processXSL(XSLProcessor.java:264)
         at oracle.xdo.parser.v2.XSLProcessor.processXSL(XSLProcessor.java:150)
         at oracle.xdo.parser.v2.XSLProcessor.processXSL(XSLProcessor.java:187)
         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java(Compiled Code))
         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java(Compiled Code))
         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java(Compiled Code))
         at java.lang.reflect.Method.invoke(Method.java(Compiled Code))
         at oracle.apps.xdo.common.xml.XSLT10gR1.invokeProcessXSL(XSLT10gR1.java(Compiled Code))
         at oracle.apps.xdo.common.xml.XSLT10gR1.transform(XSLT10gR1.java(Compiled Code))
         at oracle.apps.xdo.common.xml.XSLT10gR1.transform(XSLT10gR1.java:233)
         at oracle.apps.xdo.common.xml.XSLTWrapper.transform(XSLTWrapper.java:177)
         at oracle.apps.xdo.template.fo.util.FOUtility.generateFO(FOUtility.java:1044)
         at oracle.apps.xdo.template.fo.util.FOUtility.generateFO(FOUtility.java:997)
         at oracle.apps.xdo.template.fo.util.FOUtility.generateFO(FOUtility.java:212)
         at oracle.apps.xdo.template.FOProcessor.createFO(FOProcessor.java:1657)
         at oracle.apps.xdo.template.FOProcessor.generate(FOProcessor.java:967)
         at oracle.apps.xdo.oa.schema.server.TemplateHelper.runProcessTemplate(TemplateHelper.java:5888)
         at oracle.apps.xdo.oa.schema.server.TemplateHelper.processTemplate(TemplateHelper.java:3438)
         at oracle.apps.xdo.oa.schema.server.TemplateHelper.processTemplate(TemplateHelper.java:3527)
         at oracle.apps.fnd.cp.opp.XMLPublisherProcessor.process(XMLPublisherProcessor.java:247)
         at oracle.apps.fnd.cp.opp.OPPRequestThread.run(OPPRequestThread.java:157)
    [6/20/11 9:59:51 PM] [15905:RT2458306] Completed post-processing actions for request 2458306.
    java.lang.OutOfMemoryError
         at java.io.ObjectOutputStream$HandleTable.growSpine(ObjectOutputStream.java(Compiled Code))
         at java.io.ObjectOutputStream$HandleTable.assign(ObjectOutputStream.java(Inlined Compiled Code))
         at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java(Compiled Code))
         at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java(Compiled Code))
         at java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java(Compiled Code))
         at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java(Compiled Code))
         at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java(Compiled Code))
         at java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java(Compiled Code))
         at java.util.Vector.writeObject(Vector.java(Inlined Compiled Code))
         at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java(Compiled Code))
         at java.lang.reflect.Method.invoke(Method.java(Compiled Code))
         at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java(Compiled Code))
         at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java(Compiled Code))
         at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java(Compiled Code))
         at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java(Compiled Code))
         at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java(Inlined Compiled Code))
         at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java(Compiled Code))
         at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java(Compiled Code))
         at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java(Compiled Code))
         at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java(Compiled Code))
         at oracle.ias.cache.group.StreamHandler.write(Unknown Source)
         at oracle.ias.cache.group.EndPoint.write(Unknown Source)
         at oracle.ias.cache.group.Transport.syncMulticast(Unknown Source)
         at oracle.ias.cache.group.Transport.multicast(Unknown Source)
         at oracle.ias.cache.group.Transport.multicast(Unknown Source)
         at oracle.ias.cache.group.Monitor.ping(Unknown Source)
         at oracle.ias.cache.group.Monitor.run(Unknown Source)
    DG318: Heap dump file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/heapdump1511652.1308591323.phd
    JVMDG303: JVM Requesting Java core file
    JVMDG304: Java core file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/javacore1511652.1308591369.txt
    JVMDG274: Dump Handler has Processed OutOfMemory.
    JVMST109: Insufficient space in Javaheap to satisfy allocation request
    JVMDG217: Dump Handler is Processing OutOfMemory - Please Wait.
    JVMDG315: JVM Requesting Heap dump file
    ...........................................JVMDG318: Heap dump file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/heapdump1511652.1308591404.phd
    JVMDG303: JVM Requesting Java core file
    JVMDG304: Java core file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/javacore1511652.1308591451.txt
    JVMDG274: Dump Handler has Processed OutOfMemory.
    JVMST109: Insufficient space in Javaheap to satisfy allocation request
    JVMDG217: Dump Handler is Processing OutOfMemory - Please Wait.
    JVMDG315: JVM Requesting Heap dump file
    ...........................................JVMDG318: Heap dump file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/heapdump1511652.1308591486.phd
    JVMDG303: JVM Requesting Java core file
    JVMDG304: Java core file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/javacore1511652.1308591533.txt
    JVMDG274: Dump Handler has Processed OutOfMemory.
    JVMST109: Insufficient space in Javaheap to satisfy allocation request
    JVMDG217: Dump Handler is Processing OutOfMemory - Please Wait.
    JVMDG315: JVM Requesting Heap dump file
    ...........................................JVMDG318: Heap dump file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/heapdump1511652.1308591569.phd
    JVMDG303: JVM Requesting Java core file
    JVMDG304: Java core file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/javacore1511652.1308591614.txt
    JVMDG274: Dump Handler has Processed OutOfMemory.
    JVMST109: Insufficient space in Javaheap to satisfy allocation request
    JVMDG217: Dump Handler is Processing OutOfMemory - Please Wait.
    JVMDG315: JVM Requesting Heap dump file
    ...........................................JVMDG318: Heap dump file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/heapdump1511652.1308591652.phd
    JVMDG303: JVM Requesting Java core file
    JVMDG304: Java core file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/javacore1511652.1308591700.txt
    JVMDG274: Dump Handler has Processed OutOfMemory.
    JVMST109: Insufficient space in Javaheap to satisfy allocation request
    JVMDG217: Dump Handler is Processing OutOfMemory - Please Wait.
    JVMDG315: JVM Requesting Heap dump file
    ...........................................JVMDG318: Heap dump file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/heapdump1511652.1308591734.phd
    JVMDG303: JVM Requesting Java core file
    JVMDG304: Java core file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/javacore1511652.1308591780.txt
    JVMDG274: Dump Handler has Processed OutOfMemory.
    JVMST109: Insufficient space in Javaheap to satisfy allocation request
    JVMDG217: Dump Handler is Processing OutOfMemory - Please Wait.
    JVMDG315: JVM Requesting Heap dump file
    ...........................................JVMDG318: Heap dump file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/heapdump1511652.1308591815.phd
    JVMDG303: JVM Requesting Java core file
    JVMDG304: Java core file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/javacore1511652.1308591861.txt
    JVMDG274: Dump Handler has Processed OutOfMemory.
    JVMST109: Insufficient space in Javaheap to satisfy allocation request
    JVMDG217: Dump Handler is Processing OutOfMemory - Please Wait.
    JVMDG315: JVM Requesting Heap dump file
    ...........................................JVMDG318: Heap dump file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/heapdump1511652.1308591900.phd
    JVMDG303: JVM Requesting Java core file
    JVMDG304: Java core file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/javacore1511652.1308591946.txt
    JVMDG274: Dump Handler has Processed OutOfMemory.
    JVMST109: Insufficient space in Javaheap to satisfy allocation request
    JVMXE003
    JVMDG217: Dump Handler is Processing OutOfMemory - Please Wait.
    JVMDG315: JVM Requesting Heap dump file
    ...........................................JVMDG318: Heap dump file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/heapdump1511652.1308591981.phd
    JVMDG303: JVM Requesting Java core file
    JVMDG304: Java core file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/javacore1511652.1308592027.txt
    JVMDG274: Dump Handler has Processed OutOfMemory.
    JVMST109: Insufficient space in Javaheap to satisfy allocation request
    JVMDG217: Dump Handler is Processing OutOfMemory - Please Wait.
    JVMDG315: JVM Requesting Heap dump file
    ...........................................JVMDG318: Heap dump file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/heapdump1511652.1308592061.phd
    JVMDG303: JVM Requesting Java core file
    JVMDG304: Java core file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/javacore1511652.1308592109.txt
    JVMDG274: Dump Handler has Processed OutOfMemory.
    JVMST109: Insufficient space in Javaheap to satisfy allocation request
    JVMDG217: Dump Handler is Processing OutOfMemory - Please Wait.
    JVMDG315: JVM Requesting Heap dump file
    ...........................................JVMDG318: Heap dump file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/heapdump1511652.1308592143.phd
    JVMDG303: JVM Requesting Java core file
    JVMDG304: Java core file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/javacore1511652.1308592189.txt
    JVMDG274: Dump Handler has Processed OutOfMemory.
    JVMST109: Insufficient space in Javaheap to satisfy allocation request
    JVMDG217: Dump Handler is Processing OutOfMemory - Please Wait.
    JVMDG315: JVM Requesting Heap dump file
    ...........................................JVMDG318: Heap dump file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/heapdump1511652.1308592224.phd
    JVMDG303: JVM Requesting Java core file
    JVMDG304: Java core file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/javacore1511652.1308592270.txt
    JVMDG274: Dump Handler has Processed OutOfMemory.
    JVMST109: Insufficient space in Javaheap to satisfy allocation request
    JVMDG217: Dump Handler is Processing OutOfMemory - Please Wait.
    JVMDG315: JVM Requesting Heap dump file
    ...........................................JVMDG318: Heap dump file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/heapdump1511652.1308592305.phd
    JVMDG303: JVM Requesting Java core file
    JVMDG304: Java core file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/javacore1511652.1308592351.txt
    JVMDG274: Dump Handler has Processed OutOfMemory.
    JVMST109: Insufficient space in Javaheap to satisfy allocation request
    JVMDG217: Dump Handler is Processing OutOfMemory - Please Wait.
    JVMDG315: JVM Requesting Heap dump file
    ...........................................JVMDG318: Heap dump file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/heapdump1511652.1308592385.phd
    JVMDG303: JVM Requesting Java core file
    JVMDG304: Java core file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/javacore1511652.1308592433.txt
    JVMDG274: Dump Handler has Processed OutOfMemory.
    JVMST109: Insufficient space in Javaheap to satisfy allocation request
    JVMDG217: Dump Handler is Processing OutOfMemory - Please Wait.
    JVMDG315: JVM Requesting Heap dump file
    ...........................................JVMDG318: Heap dump file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/heapdump1511652.1308592467.phd
    JVMDG303: JVM Requesting Java core file
    JVMDG304: Java core file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/javacore1511652.1308592513.txt
    JVMDG274: Dump Handler has Processed OutOfMemory.
    JVMST109: Insufficient space in Javaheap to satisfy allocation request
    JVMDG217: Dump Handler is Processing OutOfMemory - Please Wait.
    JVMDG315: JVM Requesting Heap dump file
    ...........................................JVMDG318: Heap dump file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/heapdump1511652.1308592547.phd
    JVMDG303: JVM Requesting Java core file
    JVMDG304: Java core file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/javacore1511652.1308592593.txt
    JVMDG274: Dump Handler has Processed OutOfMemory.
    JVMST109: Insufficient space in Javaheap to satisfy allocation request
    JVMDG217: Dump Handler is Processing OutOfMemory - Please Wait.
    JVMDG315: JVM Requesting Heap dump file
    ...........................................JVMDG318: Heap dump file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/heapdump1511652.1308592628.phd
    JVMDG303: JVM Requesting Java core file
    JVMDG304: Java core file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/javacore1511652.1308592674.txt
    JVMDG274: Dump Handler has Processed OutOfMemory.
    JVMST109: Insufficient space in Javaheap to satisfy allocation request
    JVMDG217: Dump Handler is Processing OutOfMemory - Please Wait.
    JVMDG315: JVM Requesting Heap dump file
    ...........................................JVMDG318: Heap dump file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/heapdump1511652.1308592708.phd
    JVMDG303: JVM Requesting Java core file
    JVMDG304: Java core file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxx/javacore1511652.1308592755.txt
    JVMDG274: Dump Handler has Processed OutOfMemory.
    JVMST109: Insufficient space in Javaheap to satisfy allocation request
    JVMXE003
    JVMST109: Insufficient space in Javaheap to satisfy allocation request
    how to get through this error?
    Thankz
    ApPsMaSti

    Please see these MOS docs.
    XML Publisher Report Issues [ID 862644.1]
    Output Post Processor (OPP) Log Contains Error "java.lang.OutOfMemoryError: Java heap space" Error [ID 1268217.1]
    Output Post Processor (OPP) Log Contains Error "java.lang.OutOfMemoryError" [ID 1266368.1]
    OPP Service Log for the 'Create Accounting' process shows 'java.lang.OutOfMemoryError: Java heap space ' Error [ID 1129283.1]
    Retro-Notifications Report (Enhanced) - PDF Errors With 'java.lang.OutOfMemoryError' [ID 557898.1]
    Costing Summary Rep Errors with Jvmst109: Insufficient Space In Javaheap [ID 391131.1]
    Thanks,
    Hussein

  • Native Memory Area

    JVM Memory = Heap + Non-Heap
    I have configured JVM Memory as 1.5 GB. (OS is Windows) Perm Gen as 74 MB. In between i get "unable to create native threads" issue. I understand that a process in Windows can use a maximum memory of 2 GB.
    1. Is the NATIVE MEMORY space part of Non-Heap? Or is it the remaining of (2GB - (HEAP+NON_HEAP)) ?
    2. Is there a way to get the NATIVE MEMORY SPACE used by the java instance?

    I doubt the answers to any of those matter to your problem.
    If you have the heap maxed out and you are getting that error then you are probably just creating too many threads.
    If you are doing that on purpose then you need to redesign.
    If you are doing it accidently then you need to find the bug that keeps the threads active and fix it.

Maybe you are looking for

  • Why is this RSS Feed not working?

    Here is the code I used on the RSS Parser file. Yet when I open the flash viewer no changes have been made from the original example I pulled this from. Sorry, the code is listed twice. The second version is when I used "attach code" and I can't seem

  • Transfer purchases from iPhone

    I execute this command but the tracks are still listed as unable to locate. Help please:)

  • Web Sharing Won't Start Up.

    I was using My Powerbook successfully to develop websites using php and apache but suddenly when I upgraded to 10.4.6 web sharing in the system preferences just hangs when it is selected. I get a message saying it is starting up but it never gets as

  • RSR_OLAP_BADI not able to get it working

    Hi all I have been trying to impliment the above badi but it does not seem to execute any of the code. Please advise if the following will work, I need to define a virtual characteristic to be populated with 'Full' / 'Partial' based on comparing two

  • Has anybody with positive experience Safari on VISTA?

    Can someone with experience tell me if Safari is better than the Windows Internet Explorer-7 on VISTA. My Apple software keek prompting me to install Safari 3.1 on my windows vista. In another forum, on opinion was that safari VISTA has a risk of una