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 > -- 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
