Simple dynamic language using invokedynamic

[Rémi Forax]

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