![]() V compiler_thread_entry(JavaThread*, Thread*)+0x18 V CompileBroker::compiler_thread_loop()+0x567 V CompileBroker::invoke_compiler_on_method(CompileTask*)+0xda1 V C2Compiler::compile_method(ciEnv*, ciMethod*, int)+0x1b4 V Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool, bool)+0x12ef V PhaseChaitin::Register_Allocate()+0x78a ![]() V Arena::grow(unsigned int, AllocFailStrategy::AllocFailEnum)+0x2c V Chunk::operator new(unsigned int, AllocFailStrategy::AllocFailEnum, unsigned int)+0xe4 V report_vm_out_of_memory(char const*, int, unsigned int, VMErrorType, char const*)+0x55 Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) T H R E A D -Ĭurrent thread (0x20fafc00): JavaThread "C2 CompilerThread0" daemon ![]() Default location: /data/home/yrodiere/core or core.5577 # Java VM: Java HotSpot(TM) Server VM (25.66-b17 mixed mode linux-x86 ) # This output file may be truncated or incomplete. # Set larger code cache with -XX:ReservedCodeCacheSize= # Decrease Java thread stack sizes (-Xss) # In 32 bit mode, the process size limit was hit # The system is out of physical RAM or swap space # Native memory allocation (malloc) failed to allocate 3703608 bytes for Chunk::new # There is insufficient memory for the Java Runtime Environment to continue. No simple step-by-step process, unfortunately. STEPS TO FOLLOW TO REPRODUCE THE PROBLEM : THE PROBLEM WAS REPRODUCIBLE WITH -server FLAG: Did not try THE PROBLEM WAS REPRODUCIBLE WITH -Xint FLAG: Did not try This might be the reason that the issue wasn't spotted on our production server (1.8.0_65, CentOS 64bit) which has been running a similar application for almost a month: that application has been built using a 1.7 JDK. ![]() I'm talking about the exact same java code (we don't use any Java 8 feature at the moment) and the exact same JVM (1.8.0_66), but different bytecode generated by a different JDK. Whenever my application is built against a JDK7, everything runs just fine. Strange thing is: I can only reproduce the crash it if the application was built against JDK8. This is normally an ~1 hour operation mainly due to heavy disk and database I/O, but instead it crashes only seconds after starting. I can reproduce it with near certainty when triggering a full Lucene indexing on my custom application (running in a tomcat server) just after starting it. I joined the log of a crash on a 1.8.0_66, but I also experienced it on a 1.8.0_65. The log file always mention an issue in the compiler thread, in allocation.cpp. The JVM seems to crash randomly, but generally when executing resource-consuming operations. Running a web application on a Tomcat Server (7.0.59). Java HotSpot(TM) Server VM (build 25.66-b17, mixed mode) Java(TM) SE Runtime Environment (build 1.8.0_66-b17)
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |