It's more a GC crash, with more memory you don't trigger the GC, that why it's working fine. In the dump of your previous email:
VM_Operation (0x0090f7b8): GenCollectForAllocation, mode: safepoint, requested by thread 0x003e7000 Rémi Chanwit Kaewkasi a écrit : > A quick update. It seems to be the out-of-memory crash. > I re-ran with: > > $ java -Xms512M -Xmx512M -cp ".;./target/classes" -Xint > -XX:+EnableInvokeDynamic g7.tests.classgen.Fib > 5 > 55 > 610 > 6765 > 75025 > 832040 > 9227465 > > And thing works fine. > > Chanwit > > On Mon, Jun 22, 2009 at 2:28 PM, Chanwit Kaewkasi<[email protected]> wrote: > >> Hello Christian, >> >> Here's the crash report, after it started to run Fib(35). >> >> $ java -cp ".;./target/classes" -Xint -XX:+EnableInvokeDynamic >> g7.tests.classgen.Fib >> 5 >> 55 >> 610 >> 6765 >> 75025 >> 832040 >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # Internal Error (signature.cpp:60), pid=37560, tid=37408 >> # Error: expecting ( >> # >> # JRE version: 7.0-b61 >> # Java VM: Java HotSpot(TM) Client VM (16.0-b04 interpreted mode, >> sharing windows-x86 ) >> # If you would like to submit a bug report, please visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # >> >> --------------- T H R E A D --------------- >> >> Current thread (0x02b07c00): VMThread [stack: 0x02b70000,0x02bc0000] >> [id=37408] >> >> Stack: [0x02b70000,0x02bc0000], sp=0x02bbf200, free space=13c02bbf210k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native >> code) >> V [jvm.dll+0x1f34e0] >> V [jvm.dll+0xa232a] >> V [jvm.dll+0x1accc8] >> V [jvm.dll+0xccc99] >> V [jvm.dll+0xcd29b] >> V [jvm.dll+0xcd4e8] >> V [jvm.dll+0xcd545] >> V [jvm.dll+0x1787db] >> V [jvm.dll+0x178a6d] >> V [jvm.dll+0x178ddb] >> V [jvm.dll+0xd8366] >> V [jvm.dll+0x16a294] >> V [jvm.dll+0xb3ab9] >> V [jvm.dll+0xb3bd2] >> V [jvm.dll+0x1dad35] >> V [jvm.dll+0x1db10a] >> V [jvm.dll+0x1a13a4] >> V [jvm.dll+0xc7edf] >> V [jvm.dll+0xa4a8c] >> V [jvm.dll+0xc8f1c] >> V [jvm.dll+0x7eadb] >> V [jvm.dll+0x1f390b] >> V [jvm.dll+0x1f61a3] >> V [jvm.dll+0x1f542e] >> V [jvm.dll+0x1f577c] >> V [jvm.dll+0x1f5ba2] >> V [jvm.dll+0x17eabc] >> C [msvcr71.dll+0x9565] >> C [kernel32.dll+0xb713] >> >> VM_Operation (0x0090f7b8): GenCollectForAllocation, mode: safepoint, >> requested by thread 0x003e7000 >> >> >> --------------- P R O C E S S --------------- >> >> Java Threads: ( => current thread ) >> 0x02b1c800 JavaThread "Low Memory Detector" daemon [_thread_blocked, >> id=37628, stack(0x02d50000,0x02da0000)] >> 0x02b16400 JavaThread "CompilerThread0" daemon [_thread_blocked, >> id=37636, stack(0x02d00000,0x02d50000)] >> 0x02b14c00 JavaThread "Attach Listener" daemon [_thread_blocked, >> id=37616, stack(0x02cb0000,0x02d00000)] >> 0x02b24400 JavaThread "Signal Dispatcher" daemon [_thread_blocked, >> id=37504, stack(0x02c60000,0x02cb0000)] >> 0x02b0dc00 JavaThread "Finalizer" daemon [_thread_blocked, id=37932, >> stack(0x02c10000,0x02c60000)] >> 0x02b09000 JavaThread "Reference Handler" daemon [_thread_blocked, >> id=38044, stack(0x02bc0000,0x02c10000)] >> 0x003e7000 JavaThread "main" [_thread_blocked, id=37412, >> stack(0x008c0000,0x00910000)] >> >> Other Threads: >> =>0x02b07c00 VMThread [stack: 0x02b70000,0x02bc0000] [id=37408] >> 0x02b25400 WatcherThread [stack: 0x02da0000,0x02df0000] [id=37976] >> >> VM state:at safepoint (normal execution) >> >> VM Mutex/Monitor currently owned by a thread: ([mutex/lock_event]) >> [0x003e6178] Threads_lock - owner thread: 0x02b07c00 >> [0x003e6588] Heap_lock - owner thread: 0x003e7000 >> >> Heap >> def new generation total 960K, used 895K [0x229b0000, 0x22ab0000, >> 0x22e90000) >> eden space 896K, 99% used [0x229b0000, 0x22a8fff8, 0x22a90000) >> from space 64K, 0% used [0x22a90000, 0x22a90000, 0x22aa0000) >> to space 64K, 1% used [0x22aa0000, 0x22aa0350, 0x22ab0000) >> tenured generation total 4096K, used 0K [0x22e90000, 0x23290000, >> 0x269b0000) >> the space 4096K, 0% used [0x22e90000, 0x22e90000, 0x22e90200, 0x23290000) >> compacting perm gen total 12288K, used 414K [0x269b0000, 0x275b0000, >> 0x2a9b0000) >> the space 12288K, 3% used [0x269b0000, 0x26a17900, 0x26a17a00, >> 0x275b0000) >> ro space 8192K, 67% used [0x2a9b0000, 0x2af197d0, 0x2af19800, 0x2b1b0000) >> rw space 12288K, 53% used [0x2b1b0000, 0x2b8153a8, 0x2b815400, >> 0x2bdb0000) >> >> >> On Mon, Jun 22, 2009 at 2:15 PM, Christian >> Thalinger<[email protected]> wrote: >> >>> Rémi Forax wrote: >>> >>>> run with -Xint, the JIT doesn't work in b61, >>>> >>> I also thought it might be the compiler kicking in, but Chanwit's >>> command line contains -Xint. So I think it might be something different. >>> >>> >>>> I think it should work with latest patches from mlvm repo. >>>> >>> No, sorry, indy.compiler.patch does not work yet. I hope John already >>> has an easy way around the (hopefully) last problem. >>> >>> -- Christian >>> _______________________________________________ >>> mlvm-dev mailing list >>> [email protected] >>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>> >>> >> >> -- >> Chanwit Kaewkasi >> PhD Candidate, >> Centre for Novel Computing >> School of Computer Science >> The University of Manchester >> Oxford Road >> Manchester >> M13 9PL, UK >> >> > > > > _______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
