Simple dynamic language using invokedynamic

Chanwit Kaewkasi chanwit at gmail.com
Mon Jun 22 06:39:28 PDT 2009


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<chanwit at gmail.com> 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<Christian.Thalinger at sun.com> 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
>> mlvm-dev at openjdk.java.net
>> 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



More information about the mlvm-dev mailing list