Can anybody help me with this porting problem?

[chenjie]

Tom, Steve:
Thank you very much, your advice are very valuable to me,I will try it
later.

Tom Rodriguez дµÀ:
> The general strategy for debugging compiler related problems is to
> narrow down what gets compiled using -XX:CompileOnly so that as little
> compiled code as possible is involved.  I'd probably try it with just
> -XX:CompileOnly=java/lang/Thread.current and see whether it works or
> not.  You might have to widen the number of things which get compiled if
> the problem is an interaction between multiple pieces of code.  Also
> it's useful to test with -Xcomp since this forces the generation of
> compiled code for everything early so it makes for a more repeatable
> debugging experience.  Once you've done that you probably want to figure
> out whether it happens the first time it's called or not.  If it happens
> the first time then I think you want to trace through the whole
> execution of the invoke to see how it goes wrong.  Since we haven't open
> sourced the disassembler yet PrintNMethods and PrintNativeNMethods won't
> give you disassembly but they will print out the bounds of the generated
> code that you can use to set breakpoints in generated code.  Setting
> breakpoints before printing in nmethod.cpp would allow you to find the
> pc in the generated code you want to set your breakpoint at.
>
> Since you're bringing up a system from scratch it might be worth writing
> a little test case which tests returning all types of values from both
> normal Java methods and native methods and possibly with different
> permutations of arguments that verifies that the expected values are
> passed or returned.  You'd probably want to run it with -XX:-Inline to
> make sure you're really testing returning of values and not just testing
> inlining.  I've written this before but I don't think I kept it and I
> don't think we have a standard version of this in our tests either.
> Even if we didn't we haven't open sourced the tests yet so it wouldn't help.
>
> tom
>
> chenjie wrote:
>   
>> 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.
>>
>>     
>
>
>