Can anybody help me with this porting problem?
chenjie
chenj at lemote.com
Wed Aug 8 18:45:11 PDT 2007
Thank you everybody, I have find the reason, it is really a stupid
error. when return from
native in native_wrapper, if the return value is a oop type, it is
really the oop 's handle
(address), So it needs to load the real oop from the oop addr, I forget
to load it but use the
return value as a oop directly .
-XX:CompileOnly is quit useful, it is a pity I ignore it before.
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.
>>>
>>>
>>>
>>
>>
>
>
>
>
More information about the hotspot-dev
mailing list