Can anybody help me with this porting problem?

Tom Rodriguez Thomas.Rodriguez at Sun.COM
Tue Aug 7 08:52:12 PDT 2007


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