Can anybody help me with this porting problem?

steve goldman Steve.Goldman at Sun.COM
Tue Aug 7 06:44:41 PDT 2007


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().

-- 
Steve



More information about the hotspot-dev mailing list