Can anybody help me with this porting problem?
chenjie
chenj at lemote.com
Wed Aug 8 19:04:02 PDT 2007
Now My porting JVM6 can run Java2Demo.jar!
chenjie дµÀ:
> 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