Re: Bug with invokeArguments on x64

2011-01-04 Thread John Rose
On Jan 3, 2011, at 9:03 AM, Rémi Forax wrote:

> Hi Christian,
> 
> On 01/03/2011 05:41 PM, Christian Thalinger wrote:
>> On Dec 27, 2010, at 12:30 PM, Rémi Forax wrote:
>>> Hi guys,
>>> this code crash with jdk7b123 on x64,
>>> and on x32 it raises a CCE but it should raise a WrongMethodTypeException.
>> 
>> The crash should be fixed by:
>> 
>> 7007377: JSR 292 MethodHandlesTest.testCastFailure fails on SPARC with 
>> -Xcomp +DeoptimizeALot
>> 
>> which will be in HS20.0-b05.
>> 
>> But about the WrongMethodTypeException, why do you think that one should be 
>> thrown instead of a CCE?
> 
> because this is what the doc says:
> http://download.java.net/jdk7/docs/api/java/dyn/MethodHandle.html#invokeWithArguments%28java.lang.Object...%29
> 
>> -- Christian

The doc says three things:

1. ...as if via invokeGeneric from a call site which mentions only the type 
Object, and whose arity is the length of the argument array.

2. Because of the action of the asType step, the following argument conversions 
are applied as necessary: ... reference casting

3. Throws: WrongMethodTypeException - if the target's type cannot be adjusted 
to take the arguments

Point 2 is the source of the ClassCastException, which is correct.

A WMTE is thrown only if asType would also throw it.  (This should be made 
clearer.)

If there is no type-handler, the asType conversion can throw WMTE for arity 
mismatch or primitive narrowing, but it never throws WMTE just because of a 
reference type mismatch.

If there is a type-handler (this is a provisional, controversial feature) any 
method-type mismatch will be referred to the type-handler (as if via asType), 
and the type-handler takes responsibility for making up the mismatch or 
throwing WMTE.

-- John
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev


Re: bad class file crash the VM

2011-01-04 Thread John Rose
On Jan 2, 2011, at 6:42 AM, Rémi Forax wrote:

> This means there is a bug in my code but also
> that there is a bug in the VM which should reject the bad class file
> instead of crashing.

Try "java -Xverify:all".  If the class file fails verification *but* the 
verifier is not used, the JVM is allowed to be unpredictable.

-- John
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev


Re: bad class file crash the VM

2011-01-04 Thread Rémi Forax

On 01/05/2011 01:31 AM, John Rose wrote:

On Jan 2, 2011, at 6:42 AM, Rémi Forax wrote:


This means there is a bug in my code but also
that there is a bug in the VM which should reject the bad class file
instead of crashing.

Try "java -Xverify:all".  If the class file fails verification *but* the 
verifier is not used, the JVM is allowed to be unpredictable.

-- John


The class file is verified :(

[fo...@localhost tmp]$ java -XX:+UnlockExperimentalVMOptions 
-XX:+EnableInvokeDynamic -Xverify:all IndyTest

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00a68ef7, pid=26924, tid=1444720
#
# JRE version: 7.0-b123
# Java VM: Java HotSpot(TM) Server VM (20.0-b04 mixed mode linux-x86 )
# Problematic frame:
# V  [libjvm.so+0x32eef7]  JavaThread::last_frame()+0xa7
#
# An error report file with more information is saved as:
# /tmp/hs_err_pid26924.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#
Aborted (core dumped)

Rémi
PS: I've put the hotspot error log as attachment

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00a68ef7, pid=26924, tid=1444720
#
# JRE version: 7.0-b123
# Java VM: Java HotSpot(TM) Server VM (20.0-b04 mixed mode linux-x86 )
# Problematic frame:
# V  [libjvm.so+0x32eef7]  JavaThread::last_frame()+0xa7
#
# 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 (0xf7604400):  JavaThread "main" [_thread_in_vm, id=26925, 
stack(0x0011,0x00161000)]

siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), 
si_addr=0xfffc

Registers:
EAX=0x, EBX=0x00e7fc1c, ECX=0x0015ff9c, EDX=0x
ESP=0x0015fe24, EBP=0x0015fe48, ESI=0xf7604400, EDI=0x0015ff9c
EIP=0x00a68ef7, EFLAGS=0x00010216, CR2=0xfffc

Top of Stack: (sp=0x0015fe24)
0x0015fe24:   0001 0015fe48 00a68e5e 0015fee4
0x0015fe34:    f760476c 00e7fc1c 
0x0015fe44:   f7604400 0015fff8 00b02eaf 0015ff9c
0x0015fe54:   f7604400  f76046dc 00af6834
0x0015fe64:   0015ff4c f7604400 b076662c b076662c
0x0015fe74:   0015ffd4 0015ffb4 0015ff9c 0015fee4
0x0015fe84:   0015ffd8 f760476c 0400 b0766678
0x0015fe94:   000337b8  0010 0015ff70 

Instructions: (pc=0x00a68ef7)
0x00a68ed7:   5d c2 04 00 90 8d 74 26 00 8b 96 10 01 00 00 8b
0x00a68ee7:   86 08 01 00 00 89 07 89 47 14 89 57 10 83 ec 0c
0x00a68ef7:   8b 40 fc 89 47 04 50 eb 96 55 89 e5 56 53 e8 00
0x00a68f07:   00 00 00 5b 81 c3 12 6d 41 00 8b 45 10 8b 75 08 

Register to memory mapping:

EAX=0x is an unknown value
EBX=0x00e7fc1c:  in 
/usr/jdk/i586/jdk1.7.0/jre/lib/i386/server/libjvm.so at 0x0073a000
ECX=0x0015ff9c is pointing into the stack for thread: 0xf7604400
EDX=0x is an unknown value
ESP=0x0015fe24 is pointing into the stack for thread: 0xf7604400
EBP=0x0015fe48 is pointing into the stack for thread: 0xf7604400
ESI=0xf7604400 is a thread
EDI=0x0015ff9c is pointing into the stack for thread: 0xf7604400


Stack: [0x0011,0x00161000],  sp=0x0015fe24,  free space=319k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x32eef7]  JavaThread::last_frame()+0xa7
V  [libjvm.so+0x3c8eaf]  java_lang_Throwable::fill_in_stack_trace(Handle, 
Thread*)+0x25f
V  [libjvm.so+0x3c95bb]  java_lang_Throwable::fill_in_stack_trace(Handle)+0x5b
V  [libjvm.so+0x3235f8]  Exceptions::throw_stack_overflow_exception(Thread*, 
char const*, int)+0xb8
V  [libjvm.so+0x3c129b]  JavaCalls::call_helper(JavaValue*, methodHandle*, 
JavaCallArguments*, Thread*)+0x1cb
V  [libjvm.so+0x557239]  os::os_exception_wrapper(void (*)(JavaValue*, 
methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, 
JavaCallArguments*, Thread*)+0x19
V  [libjvm.so+0x3c02df]  JavaCalls::call(JavaValue*, methodHandle, 
JavaCallArguments*, Thread*)+0x2f
V  [libjvm.so+0x3cb63a]  jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, 
JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*)+0x21a
V  [libjvm.so+0x3d1a1a]  jni_CallStaticVoidMethod+0xba
C  [libjli.so+0x25f0]  JavaMain+0x560
C  [libpthread.so.0+0x5f19]  abort@@GLIBC_2.0+0x5f19


---  P R O C E S S  ---

Java Threads: ( => current thread )
  0xaf924800 JavaThread "Low Memory Detector" daemon [_thread_blocked, 
id=26941, stack(0x02c16000,0x02c67000)]
  0xaf922800 JavaThread "C2 CompilerThread1" daemon [_thread_blocked, id=26940, 
stack(0x0667,0x066f1000)]
  0xaf920800 JavaThread "C2 CompilerThread0" daemon [_thread_blocked, id=26939, 
stack(0x0785,0x078d1000)]
  0xaf91f000 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=26938, 
stack(0x02905000,0x02956000)]
  0xaf90c400 JavaThread "Finalizer" daemon [_thread_blocked, id=26937, 
stack(0x00588000,0x005d9000)]
  0xaf90ac00 JavaThread "Reference Handler" daemon [_thread_blocked, id=26936, 
stack(0x

Re: bad class file crash the VM

2011-01-04 Thread John Rose
Nice.  Thanks!  -- John

On Jan 4, 2011, at 5:30 PM, Rémi Forax wrote:

> On 01/05/2011 01:31 AM, John Rose wrote:
>> On Jan 2, 2011, at 6:42 AM, Rémi Forax wrote:
>> 
>>> This means there is a bug in my code but also
>>> that there is a bug in the VM which should reject the bad class file
>>> instead of crashing.
>> Try "java -Xverify:all".  If the class file fails verification *but* the 
>> verifier is not used, the JVM is allowed to be unpredictable.
>> 
>> -- John
> 
> The class file is verified :(

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev


hg: mlvm/mlvm: update for latest API changes

2011-01-04 Thread john . r . rose
Changeset: 94b518bfe27e
Author:jrose
Date:  2011-01-04 22:58 -0800
URL:   http://hg.openjdk.java.net/mlvm/mlvm/rev/94b518bfe27e

update for latest API changes

! netbeans/indy-demo/nbproject/project.properties
! netbeans/indy-demo/src/FidgetDemo.java
! netbeans/indy-demo/src/GetNameDemo.java
! netbeans/indy-demo/src/Hello.java
! netbeans/indy-demo/src/PrintArgsDemo.java
! netbeans/indy-demo/src/indify/Indify.java
! netbeans/meth/nbproject/build-impl.xml
! netbeans/meth/nbproject/genfiles.properties
! netbeans/meth/nbproject/project.properties

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev


Auto Reply: hg: mlvm/mlvm: update for latest API changes

2011-01-04 Thread henrik . osterdahl
Hello,

I'm out of the office Dec 24 2010 through Jan 9 2011.

Please refer to David Cox (david.cox) and Daniel Källander (daniel.kallander).

Regards,
Henrik Österdahl
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev


updated 292 spec

2011-01-04 Thread John Rose
Here is the current version of the document:
  http://cr.openjdk.java.net/~jrose/pres/indy-javadoc-mlvm-0104/

The changes since b123 (which are few) are described here:
  http://cr.openjdk.java.net/~jrose/pres/indy-javadoc-mlvm-0104-after-1216/

As you can see from the spec, we are down to a very small number of 
"provisional" items.  These are open items which the EG is still discussing.

Happy New Year!

-- John
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev