Can anybody help me with this porting problem?

[chenjie]

steve goldman дµÀ:
> chenjie wrote:
>   
>> Can anybody help me with this porting problem?
>>
>> I am now porting JVM6 to mips archtecture, But meet a big problem . I
>> have already spended 1 week on it, but still can not solve it.can
>> anybody do me a favor giving me some advices?
>>
>> I currently use the JDK5 enviroment except "libjvm.so". when run
>> Java2Demo.jar of JDK5 demo with "-Xint" mode,It is quit regular, But
>> when run it with mixed mode, It happened a strange crash, this is the
>> error report:
>>
>>
>>
>> #
>> # An unexpected error has been detected by Java Runtime Environment:
>> #
>> # SIGUSR1 (0xa) at pc=0x2bf8c718, pid=20197, tid=16384
>> #
>> # Java VM: Java HotSpot(TM) Client VM (1.6.0-rc-b104-debug mixed mode)
>> # Problematic frame:
>> # j
>> sun.reflect.GeneratedMethodAccessor1.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0
>> #
>> # 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 (0x10020400): JavaThread "main" [_thread_in_Java, id=20197]
>>
>> siginfo:si_signo=10, si_errno=0, si_code=128, si_addr=0x00000000
>>
>> Registers:
>> i0=0x00000000, i1=0xfefeff1e, i2=0x10070354, i3=0x00000000
>> i4=0x10020ca8, i5=0x0000005a, i6=0x00000004, i7=0x10020400
>> i8=0x10020400, i9=0x00000007, i10=0xfefefefe, i11=0x32592268
>> i12=0x31fe0f38, i13=0x00000020, i14=0xfffffffe, i15=0x000000c0
>> i16=0x3259260d, i17=0x000053be, i18=0x2e034d70, i19=0x00000000
>> i20=0x00000000, i21=0x7efc46ac, i22=0x10020400, i23=0x7efc4654
>> i24=0x7efc4658, i25=0x2b18eae0, i26=0x2aac4000, i27=0x00000000
>> i28=0x2b909250, i29=0x7efc4624, i30=0x7efc4644, i31=0x2bf3cbfc
>>
>> Top of Stack: (sp=0x7efc4624)
>> 0x7efc4604: 2ac2a968 2ab0be88 2ad69530 2b909250
>> 0x7efc4614: 00000000 10020ce8 10020400 31fb5c70
>> 0x7efc4624: 7efc4624 32592600 32592850 00000000
>> 0x7efc4634: 32592648 7efc4654 00000000 7efc464c
>> 0x7efc4644: 7efc4678 2bf3cbfc 2e042080 10070354
>> 0x7efc4654: 2e037878 7efc4658 32412576 32412830
>> 0x7efc4664: 00000000 32412588 7efc4688 7efc464c
>> 0x7efc4674: 7efc4680 7efc46ac 2bf416cc 2e042080
>> 0x7efc4684: 10070354 2e0338d8 7efc468c 31ff0bbf
>> 0x7efc4694: 32023648 00000000 31ff0be0 7efc46c4
>>
>> Instructions: (pc=0x2bf8c718)
>> 0x2bf8c708: 04 00 4a 8c 10 00 8d 8d 20 08 4d 01 00 00 2e 8c
>> 0x2bf8c718: 17 00 cc 11 00 00 00 00 14 00 0e 24 10 00 cd 15
>>
>>
>> Stack: [0x7ef78000,0x7efc8000), sp=0x7efc4624, free space=305k
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
>> C=native code)
>> j
>> sun.reflect.GeneratedMethodAccessor1.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0
>> j
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+6
>> j
>> java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+111
>> j
>> java.nio.channels.spi.AbstractInterruptibleChannel.blockedOn(Lsun/nio/ch/Interruptible;)V+23
>> j java.nio.channels.spi.AbstractInterruptibleChannel.end(Z)V+1
>> j sun.nio.ch.FileChannelImpl.position(J)Ljava/nio/channels/FileChannel;+164
>> j sun.font.TrueTypeFont.readBlock(Ljava/nio/ByteBuffer;II)I+76
>> v ~StubRoutines::call_stub
>> V [libjvm.so+0x437fe0]
>> C 0x7efc4a80
>>
>>
>> --------------- P R O C E S S ---------------
>>
>> Java Threads: ( => current thread )
>> 0x101a7400 JavaThread "AWT-Shutdown" [_thread_blocked, id=20212]
>> 0x10629c00 JavaThread "AWT-XAWT" daemon [_thread_in_native, id=20211]
>> 0x10602c00 JavaThread "Java2D Disposer" daemon [_thread_blocked, id=20208]
>> 0x10089400 JavaThread "Low Memory Detector" daemon [_thread_blocked,
>> id=20204]
>> 0x10087000 JavaThread "CompilerThread0" daemon [_thread_blocked, id=20203]
>> 0x10085400 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=20202]
>> 0x10072000 JavaThread "Finalizer" daemon [_thread_blocked, id=20201]
>> 0x10070c00 JavaThread "Reference Handler" daemon [_thread_blocked, id=20200]
>> =>0x10020400 JavaThread "main" [_thread_in_Java, id=20197]
>>
>> Other Threads:
>> 0x10063c00 VMThread [id=20199]
>> 0x100ae400 WatcherThread [id=20207]
>>
>> VM state:not at safepoint (normal execution)
>>
>> VM Mutex/Monitor currently owned by a thread: None
>>
>> Heap
>> def new generation total 960K, used 652K [0x2dfb0000, 0x2e0b0000,
>> 0x2e490000)
>> eden space 896K, 65% used [0x2dfb0000, 0x2e0430f8, 0x2e090000)
>> from space 64K, 100% used [0x2e0a0000, 0x2e0b0000, 0x2e0b0000)
>> to space 64K, 0% used [0x2e090000, 0x2e090000, 0x2e0a0000)
>> tenured generation total 4096K, used 203K [0x2e490000, 0x2e890000,
>> 0x31fb0000)
>> the space 4096K, 4% used [0x2e490000, 0x2e4c2c80, 0x2e4c2e00, 0x2e890000)
>> compacting perm gen total 12288K, used 6098K [0x31fb0000, 0x32bb0000,
>> 0x35fb0000)
>> the space 12288K, 49% used [0x31fb0000, 0x325a4a18, 0x325a4c00, 0x32bb0000)
>> No shared spaces configured.
>>
>>
>> VM Arguments:
>> jvm_args: -XX:+PrintCompilation
>> java_command: Java2Demo.jar
>> Launcher Type: generic
>>
>> Environment Variables:
>> JAVA_HOME=/usr/lib/jvm/sun-java
>> CLASSPATH=.:/usr/lib/jvm/sun-java/lib
>> PATH=/usr/lib/jvm/sun-java/bin:/usr/local/bin:/usr/sbin:/bin:/sbin:/usr/bin/X11:/usr/bin
>> USERNAME=loongson
>> LD_LIBRARY_PATH=/usr/lib/jvm/sun-java/lib/mips32/client:/usr/lib/jvm/sun-java/lib/mips32:/usr/lib/jvm/sun-java/../lib/mips32
>> SHELL=/bin/bash
>> DISPLAY=:0.0
>>
>> Signal Handlers:
>> SIGSEGV: [libjvm.so+0x9ebf60], sa_mask[0]=0xffbffeff, sa_flags=0x10000008
>> SIGUSR1: [libjvm.so+0x9ebf60], sa_mask[0]=0xffbffeff, sa_flags=0x10000008
>> SIGFPE: [libjvm.so+0x7e2b5c], sa_mask[0]=0xffbffeff, sa_flags=0x10000008
>> SIGPIPE: [libjvm.so+0x7e2b5c], sa_mask[0]=0xffbffeff, sa_flags=0x10000008
>> SIGILL: [libjvm.so+0x7e2b5c], sa_mask[0]=0xffbffeff, sa_flags=0x10000008
>> SIGSTKFLT: SIG_DFL, sa_mask[0]=0x00000000, sa_flags=0x00000000
>> SIGCHLD: [libjvm.so+0x7ea1c0], sa_mask[0]=0x80000000, sa_flags=0x10000008
>> SIGHUP: [libjvm.so+0x7e40d4], sa_mask[0]=0xffbffeff, sa_flags=0x10000008
>> SIGINT: [libjvm.so+0x7e40d4], sa_mask[0]=0xffbffeff, sa_flags=0x10000008
>> SIGQUIT: [libjvm.so+0x7e40d4], sa_mask[0]=0xffbffeff, sa_flags=0x10000008
>> SIGTERM: [libjvm.so+0x7e40d4], sa_mask[0]=0xffbffeff, sa_flags=0x10000008
>> SIGCHLD: [libjvm.so+0x7ea1c0], sa_mask[0]=0x80000000, sa_flags=0x10000008
>>
>>
>> --------------- S Y S T E M ---------------
>>
>> OS:4.0
>>
>> uname:Linux 2.6.18.1lemote64 #15 Tue Mar 6 08:51:02 CST 2007 mips64
>> libc:glibc 2.3.6 linuxthreads-0.10 (fixed stack)
>> rlimit: STACK 2032k, CORE 0k, NPROC infinity, NOFILE 1024, AS infinity
>> load average:0.98 0.82 0.60
>>
>> CPU:total 1 , has_16k_page
>>
>> Memory: 16k page, physical 514768k(8896k free), swap 977888k(958704k free)
>>
>> vm_info: Java HotSpot(TM) Client VM (1.6.0-rc-b104) for linux-mips,
>> built on Aug 7 2007 17:23:13 by "root" with gcc 4.1.2 20061028
>> (prerelease) (Debian 4.1.1-19)
>>
>>
>>
>>
>> when Run it in gdb, it stop at "invokevirtual_helper" at
>> "templateTable_mips.cpp", the "oopDesc::klass_offset_in_bytes()"of recv
>> is "0xfefefefe", which is sure error, the recv is assigned in
>> "prepare_invoke"
>> as follow:
>> if (load_receiver) {
>> __ andi(AT, flags, 0xff);
>> __ shl(AT, Interpreter::stackElementScale());
>> __ add(AT, SP, AT);
>> __ lw(recv, AT, - Interpreter::expr_offset_in_bytes(1));
>> __ verify_oop(recv);
>> }
>> the value of recv is the return value of "currentThread"function, which
>> was compiled and excuted through i2c adapt just now.the return vaule of
>> "currentThread" is normal as before,So I think the SP is wrong , but SP
>> did not
>> change during invoking "currentThread".So I am confused.do any body get
>> some advices?
>>     
>
> So on return from a compiled code the execution will pass thru the code
> produced by generate_return_entry_for(). This code will restore the
> stack pointer to the value it was when currentThread() was called
> eliminating any adjustment that the i2c might have done. It would also
> convert the return value from compiled convention to interpreter
> convention for the TosState for the particular return type. Is the
> compiled return location for oop (atos) the same as what the interpreter
> use? If it isn't then when the next argument is pushed the result that
> is pushed is will be trash. In any case I suspect that your problem is
> an incompatibility between compiled/interpreted that isn't properly
> accounted for in generate_return_entry_for().
>
>   

actually , I have checked for this, when execution in compiled code
returned,
1)It went to"__ bind(interpreter_entry)", because there is no fpu stack.
2)SP,BCP , LVP(local variable pointer)restored to the right value which
saved in "jump_from_interpretered";
3)then it saved the result register in "set_vtos_entry_points";
4) it went to "invokevirtual", the function be invoked have 1
parameter,but the jvm picked the "recv" from the location which the
result value from "currentThread" saved in.

So , I guess there are problems in other place,but I can not locate it.