2 Replies Latest reply on Nov 25, 2013 5:39 AM by mohanr-JavaNet

    "CompilerThread1" java.lang.OutOfMemoryError


      This error occurs in our production server.


      Exception in thread "CompilerThread1" java.lang.OutOfMemoryError: requested 32756 bytes for ChunkPool::allocate. Out of swap space?


      1. Java HotSpot(TM) Server VM 1.5.0_16-b02 (-Xms1024m -Xmx2024m -XX:MaxPermSize=1024m)

      2. Linux 2.6.18-274.el5,i386


      Initially I thought this was a bug that was fixed. Can very long methods or classes cause this ?



        • 1. Re: "CompilerThread1" java.lang.OutOfMemoryError

          Method?  A method cannot be longer than 64k.


          If you have a class itself causing an out of memory error then it is too big - even if it is generated (which is the only way it should have gotten that way.)


          Conversely, of course, running a class, any class, and cause an out of memory error.


          Presumably of course you did check your swap space.

          • 2. Re: "CompilerThread1" java.lang.OutOfMemoryError

            I haven't replied earlier because I was tracking the code cache usage using JMX.


            I know how to gather swap details. How do you correlate swap usage and JVM crashes ? Is there a scientific way to graph the details ?


            The non-heap memory, used for JIT compilation storage, is by default about 48 MB. I gathered the data from the production VM and drew a graph using 'R'. The usage though is only about 15 MB. So it is not running out this space. But it still crashes.



            # An unexpected error has been detected by HotSpot Virtual Machine:


            #  SIGSEGV (0xb) at pc=0xf780ea10, pid=29299, tid=827308944


            # Java VM: Java HotSpot(TM) Server VM (1.5.0_16-b02 mixed mode)

            # Problematic frame:

            # V  [libjvm.so+0x23ba10]




            ---------------  T H R E A D  ---------------



            Current thread (0x319c5908):  JavaThread "CompilerThread0" daemon [_thread_in_native, id=29313]



            siginfo:si_signo=11, si_errno=0, si_code=1, si_addr=0xfff8c000




            EAX=0x00000000, EBX=0xf7b98090, ECX=0x0013466b, EDX=0x000921c9

            ESP=0x314f9e80, EBP=0x314f9e98, ESI=0x000103c1, EDI=0xfff8c000

            EIP=0xf780ea10, CR2=0xfff8c000, EFLAGS=0x00010297



            Top of Stack: (sp=0x314f9e80)

            0x314f9e80:   f9900008 00000000 f7b0709c f7b98090

            0x314f9e90:   314f9ef0 314fa090 314fa008 f772bfbb

            0x314f9ea0:   314f9f80 000103c1 f7b9f820 f7b9f820

            0x314f9eb0:   314f9ed0 314f9fd0 f7b0709c f76f2bca

            0x314f9ec0:   314f9ef0 f7b98090 314f9f18 f7b070c2

            0x314f9ed0:   f7b07120 f7b070a8 314f9f50 f7baa200

            0x314f9ee0:   314f9f80 314f9fa0 314fa0fc 314f9fe0

            0x314f9ef0:   00000000 00000000 00000001 00000000



            Instructions: (pc=0xf780ea10)

            0xf780ea00:   75 0c 8d 14 f6 8d 0c 56 c1 e1 02 c1 e9 02 39 f0

            0xf780ea10:   f3 ab c7 45 f0 00 00 00 00 73 5f 31 f6 31 ff 90



            Stack: [0x3147b000,0x314fc000),  sp=0x314f9e80,  free space=507k

            Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)

            V  [libjvm.so+0x23ba10]

            V  [libjvm.so+0x158fbb]

            V  [libjvm.so+0x1a465e]

            V  [libjvm.so+0x1a0b7a]

            V  [libjvm.so+0x149893]

            V  [libjvm.so+0x1a90c9]

            V  [libjvm.so+0x1a8a21]

            V  [libjvm.so+0x4de066]

            V  [libjvm.so+0x4d83b3]

            V  [libjvm.so+0x4386f8]

            C  [libpthread.so.0+0x5832]





            Current CompileTask:

            opto:2525      panaceaTRANweb.TRANCtlbean.etranctl.revalAccNum(I)Z (517 bytes)