harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tianwei <tianwei.sh...@gmail.com>
Subject Re: The progress of MIPS patch work
Date Sat, 02 Jan 2010 15:20:19 GMT
Hi, Charles,
   I finally made a milestone, and get the interpreter works for
"HelloWorld", the following is the result:
stw@RAYS-b0f748fa:~/test$
/home/stw/harmony/harmony-nofetch/working_vm/build/linux_mips32_gcc_debug/deploy/jdk/jre/bin/java
-Xint  HelloWorldApp
Hello World!

Please ignore the previous mail, I made a mistake to comment out the
following line in
interp_native_mips.cpp:

              case JAVA_TYPE_DOUBLE:
              case JAVA_TYPE_LONG:

                            /* MIPS ABI requires 64 bit values to be
naturally aligned.
                             * pad here and increase array size if required.
                             */
                            if ((argId & 1) != 0) {
                                  sz++;
                                  arg_words2 = (uword*)ALLOC_FRAME((sz + 2)
* sizeof(uword));
                                  if (!arg_words2) {
                                    DIE(("no memory for frame"));
                                  }
                                  memcpy(arg_words2, arg_words, argId *
sizeof(uword));
                                  FREE_FRAME(arg_words);
                                  arg_words = arg_words2;
                                  argId++;
                            }
                  Value2 val;
                  val.i64 = args[pos++].j;
                  arg_words[argId++] = val.v[0].i;
                  arg_words[argId++] = val.v[1].i;
                  break;

I  comment out the padding code, this will give me the following error, for
example:
  JNIEXPORT void JNICALL
  Java_java_util_zip_Inflater_setInputImpl (JNIEnv * env, jobject recv,
                                            jbyteArray buf, jint off, jint
len,
                                            jlong handle)
  {
............
 }

it has 6 arguments, in the interpreter, before call this JNI, if comment out
the padding code, the args is:
 (gdb) p args[4]
$88 = 512
(gdb) p args[5]
$85 = 10515904
(gdb) p args[6]
$86 = 0

args[5] and args[6] are for jlong, but the MIPS ABI need to align, so we
need to modify it as:
args[4] =512, args[5]=0
args[6] = 10515904, args[7]=0
when I enable the padding code, it works.

Other issues are mainly about get and set value for JAVA_TYPE_LONG, I
believe the original patch has some problems, my fix looks like:
                  Value2 val;
                  val.i64 = args[pos++].j;
                  arg_words[argId++] = val.v[0].i;
                  arg_words[argId++] = val.v[1].i;
                  break;


summary:
   (1) the interpreter works for "HelloWorld" based on Charles's patch on my
MIPS machines.
   (2) I only knew very little about the harmony and JVM, only use gdb and
trace to solve the problem, I will continue to
learn them.
   (3) next step, I will continue to test more cases and polish my code.

BTW,  Is there any updates for merging your patch into upstream?  Since now
I make the interpreter work, I also can help testing.

Thanks.

Tianwei
On Tue, Dec 29, 2009 at 9:13 PM, Tianwei <tianwei.sheng@gmail.com> wrote:

> Well, after two day's debugging, the root cause is that there is some
> problem with the parameter passing in original patch on my machine, some of
> the code looks like:
> --- interpreter.cpp     (revision 162)
>
> +++ interpreter.cpp     (working copy)
>
> @@ -1691,10 +1691,10 @@
>
>          case VM_DATA_TYPE_INT64:
>
>          case VM_DATA_TYPE_F8:
>
>              {
>
> -                double *vaddr = (double*) addr;
>
> -                *vaddr = frame.stack.getLong(0).d;
>
> -                frame.stack.pop(2);
>
> -                break;
>
> +             //double *vaddr = (double*) addr;
>
> +             *(I_64*)addr = frame.stack.getLong(0).i64;
>
> +             frame.stack.pop(2);
>
> +             break;
>
>              }
> ===================================================================
>
> --- interp_native_mips.cpp      (revision 162)
>
> +++ interp_native_mips.cpp      (working copy)
>              case JAVA_TYPE_DOUBLE:
>
>              case JAVA_TYPE_LONG:
>
>
> -                args[argId+0] = prevFrame.stack.pick(pos-0).u;
>
> -                args[argId+1] = prevFrame.stack.pick(pos-1).u;
>
> -                argId += 2;
>
> -                pos -= 2;
>
> -                break;
>
>
>
> +             Value2 val;
>
> +             val.i64 = prevFrame.stack.getLong(pos-1).i64;
>
> +             args[argId+0] = val.v[0].i;
>
> +             args[argId+1] = val.v[1].i;
>
> +             argId += 2;
>
> +             pos -= 2;
>
> +             break;
>
> I guess the fix is not fully right(does not handle double), but at least
> the orignal patch do not have a consistent usage for "JAVA_TYPE_LONG".
>
> Tianwei
> On Sun, Dec 27, 2009 at 8:40 PM, Tianwei <tianwei.sheng@gmail.com> wrote:
>
>> sorry, miss something for the previous trace:
>> [trace] StartLoading class [Ljava/lang/StackTraceElement; with loader
>> 0x450fc0
>> [trace] initializing class java/lang/System
>> [trace] initializing class java/lang/System STEP 2
>> [trace] StartLoading class java/lang/NoClassDefFoundError with loader
>> 0x450fc0
>> [trace] initializing class java/lang/NoClassDefFoundError
>> [trace] initializing class java/lang/NoClassDefFoundError STEP 2
>> [trace] initializing class java/lang/NoClassDefFoundErrorSTEP 6
>> [trace] class java/lang/NoClassDefFoundError initialized
>> [trace] exn_raise_object(), propagating lazy & non-destructively
>> [trace] interpreter: 0x6f3608.<init>(Ljava/lang/String;)V
>> [trace] interpreter: 0x6f3440.<init>(Ljava/lang/String;)V
>> [trace] interpreter: 0x6f31b0.<init>(Ljava/lang/String;)V
>> [trace] interpreter: 0x6f2ec8.<init>(Ljava/lang/String;)V
>> [trace] interpreter: 0x468358.<init>()V
>> [trace] interpreter: 0x6f2ec8.fillInStackTrace()Ljava/lang/Throwable;
>> [trace] interpreter static native:
>> 0x787048.getStackState()Ljava/lang/Object;
>> [trace] interpreter static native:
>> 0x787048.getStackClasses(Ljava/lang/Object;)[Ljava/lang/Class;
>>
>>
>> Does that mean it has some problem with loading
>> "[Ljava/lang/StackTraceElement"?
>>
>> Thanks.
>>
>> Tianwei
>> On Sun, Dec 27, 2009 at 8:26 PM, Tianwei <tianwei.sheng@gmail.com> wrote:
>>
>>> OK, when using  -Xtrace:harmonyvm, the tail of the trace looks like:
>>> trace] interpreter: 0x6f2740.toString()Ljava/lang/String;
>>> [trace] interpreter: 0x6f2740.toString()Ljava/lang/String;
>>> [trace] interpreter: 0x6f3498.<init>(Ljava/lang/String;)V
>>> [trace] interpreter: 0x6f32d0.<init>(Ljava/lang/String;)V
>>> [trace] interpreter: 0x6f3040.<init>(Ljava/lang/String;)V
>>> [trace] interpreter: 0x6f2d58.<init>(Ljava/lang/String;)V
>>> [trace] interpreter: 0x4682f8.<init>()V
>>> [trace] interpreter: 0x6f2d58.fillInStackTrace()Ljava/lang/Throwable;
>>> [trace] interpreter static native:
>>> 0x786ed8.getStackState()Ljava/lang/Object;
>>> [trace] interpreter static native:
>>> 0x786ed8.getStackClasses(Ljava/lang/Object;)[Ljava/lang/Class;
>>> java:
>>> /home/stw/harmony/harmony-nofetch/working_vm/vm/vmcore/src/exception/exceptions.cpp:574:
>>> exn_native_print_stack_trace: Assertion `hythread_is_suspend_enabled()'
>>> failed.
>>> Aborted
>>>
>>> Tianwei
>>>
>>> On Sun, Dec 27, 2009 at 7:59 PM, Tianwei <tianwei.sheng@gmail.com>wrote:
>>>
>>>> Hi, all,
>>>>    I met a difficult problem again. Now based on Charles's patch, I can
>>>> go further on my MIPS machine. But I met the following error when using
>>>> interpreter:
>>>> stw@RAYS-b0f748fa:~/test$
>>>> /home/stw/harmony/harmony-nofetch/working_vm/build/linux_mips32_gcc_debug/deploy/jdk/jre/bin/java
>>>> -Xint -Xtrace:vm.core  HelloWorldApp
>>>>
>>>> checking table sizes: 96/96
>>>>
>>>> checking table sizes: 96/96
>>>>
>>>> [trace] Initializing VM
>>>>
>>>> [trace] analyzing em dll libem.so
>>>>
>>>> [trace] analyzing gc.dll libgc_gen_uncomp.so
>>>>
>>>> [trace] bootstrapping initial java classes
>>>>
>>>> [trace] bootstrapping initial java classes complete
>>>>
>>>> [trace] get class methods : java/lang/Thread
>>>>
>>>> [trace] Failed to initialize new thread object, exception =
>>>> java/lang/ExceptionInInitializerError
>>>>
>>>> java/lang/ExceptionInInitializerError : (null)
>>>> java:
>>>> /home/stw/harmony/harmony-nofetch/working_vm/vm/vmcore/src/exception/exceptions.cpp:574:
>>>> exn_native_print_stack_trace: Assertion `hythread_is_suspend_enabled()'
>>>> failed.
>>>> Aborted
>>>>
>>>>
>>>> I debug the code with gdb a lot(compared with X86_64 version), but was
>>>> lost inside the large code base. I also were reading Harmony's document and
>>>> try to understand the whole framework.  But it's really very difficult ;-(
>>>> I want to know if someone can give me some suggestions for such bugs,
>>>> also are there any useful debugging tips(trace, logging facilities) for my
>>>> porting work?
>>>>
>>>> more information for the exception, I use gdb to trace the bug for the
>>>> source code is:
>>>>   void
>>>>   interpreter(StackFrame &frame) {
>>>>       while (true) {
>>>>           ip0 = *frame.ip;
>>>>          switch(ip0) {
>>>>            ...............
>>>>              case OPCODE_INVOKESTATIC:
>>>>                                  Opcode_INVOKESTATIC(frame);
>>>>                                   frame.exc =
>>>> get_current_thread_exception();
>>>>                                   if (frame.exc != 0) goto
>>>> got_exception;
>>>>                                   frame.ip += 3;
>>>>                                   break;
>>>>
>>>>       }
>>>>    got_exception:
>>>>             ................
>>>> }
>>>>
>>>> but hard to further locate the root cause.
>>>>
>>>> Any suggestions?
>>>>
>>>> Thanks very much
>>>>
>>>> Tianwei
>>>> On Thu, Dec 3, 2009 at 10:31 AM, Tianwei <tianwei.sheng@gmail.com>wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, Dec 3, 2009 at 9:01 AM, Nathan Beyer <ndbeyer@apache.org>wrote:
>>>>>
>>>>>> On Wed, Dec 2, 2009 at 7:51 AM, Tianwei <tianwei.sheng@gmail.com>
>>>>>> wrote:
>>>>>> > Hi, all,
>>>>>> >  I got some progress for applying  Charles's patch sent two
weeks
>>>>>> ago.
>>>>>> > However, I also met some hard issues which I want to ask for
>>>>>> suggestions.
>>>>>> > I am totally new for harmony development, so I want to hear
your
>>>>>> valuable
>>>>>> > suggestions for my work.
>>>>>> > My experiments step are:
>>>>>> > 1. apply the patch on X86_64 (ubuntu 9.04)
>>>>>> >    at this step, I also checkout a clean trunk, maintain two
>>>>>> directories
>>>>>> >    trunk and trunk-mips(patched by MIPS patch)
>>>>>> >  after fixing some problems, I compare the testing result(ant
test)
>>>>>> for
>>>>>> > these two versions, the result is same where I assume the modified
>>>>>> patch
>>>>>> > work on X86(no regression).
>>>>>> >  for this step, the main problems of original patch are:
>>>>>> >   a. there is some problem when using "unless", such as:
>>>>>> >      --- working_vm/make/vm/interpreter.xml  (revision 833674)
>>>>>> > +++ working_vm/make/vm/interpreter.xml  (working copy)
>>>>>> > @@ -71,6 +71,7 @@
>>>>>> >                 <exclude name="interp_native_ia32.cpp"
>>>>>> unless="is.x86"/>
>>>>>> >                 <exclude name="interp_native_ipf.cpp"
>>>>>> unless="is.ia64"/>
>>>>>> >                 <exclude name="interp_native_em64t.cpp"
>>>>>> > unless="is.x86_64"/>
>>>>>> > +                <exclude name="interp_native_mips.cpp"
>>>>>> unless="is.mips"/>
>>>>>> >             </fileset>
>>>>>>
>>>>>> Perhaps this is obvious, but is the 'is.mips' property being setup?
>>>>>> When you run 'ant echo' in the 'working_classlib' folder do you see
a
>>>>>> 'is.mips' line in with the other platforms, like this.
>>>>>>
>>>>>>     [echo]   is.windows = ${is.windows}
>>>>>>     [echo]   is.unix = true
>>>>>>     [echo]   is.linux = true
>>>>>>     [echo]   is.freebsd = ${is.freebsd}
>>>>>>     [echo]   is.macosx = ${is.macosx}
>>>>>>     [echo]   is.aix = ${is.aix}
>>>>>>     [echo]   is.zos = ${is.zos}
>>>>>>     [echo]   is.32bit = true
>>>>>>     [echo]   is.64bit = ${is.64bit}
>>>>>>     [echo]   is.x86 = true
>>>>>>     [echo]   is.x86_64 = ${is.x86_64}
>>>>>>     [echo]   is.ia64 = ${is.ia64}
>>>>>>     [echo]   is.ppc32 = ${is.ppc32}
>>>>>>     [echo]   is.ppc64 = ${is.ppc64}
>>>>>>     [echo]   is.s390 = ${is.s390}
>>>>>>     [echo]   is.s390x = ${is.s390x}
>>>>>>
>>>>>>
>>>>>> Ah, I did not see the is_mips32, but I added the line in
>>>>> common_resources/make/platform.xml where I thought it would set is_mips32
>>>>> according to $os_arch.  I think this should be set because I used this
to
>>>>> add the defineset, such as -D_MIPS_.
>>>>>
>>>>> Tianwei
>>>>>
>>>>>> >  b. the original patch has several problems under the
>>>>>> >  working_vm/vm/jitrino/src/jet directory, so I do not use the
diff
>>>>>> for that
>>>>>> > directory
>>>>>> >
>>>>>> > 2. apply the patch on my MIPS machine
>>>>>> >    at this step, I mainly fix a lot of ant make system error
since
>>>>>> the
>>>>>> > original patch did not include the makefile patch as Charles
said.
>>>>>> >    typical fixes mainly include:
>>>>>> >     a. copy the linux_ppc32.mk to linux_mips32.mk
>>>>>> >     b. comment out the ABORT where I can not find the definition
>>>>>> >     c.
>>>>>> > /home/stw/harmony/harmony-nofetch/common_resources/make/platform.xml
>>>>>> > +    <condition property="is.mips32">
>>>>>> >
>>>>>> > +        <or>
>>>>>> > +            <equals arg1="${os.arch}" arg2="mips32" />
>>>>>> > +            <equals arg1="${os.arch}" arg2="mips" />
>>>>>> > +        </or>
>>>>>> > +    </condition>
>>>>>> > +    <condition property="is.mips64">
>>>>>> > +        <equals arg1="${os.arch}" arg2="mips64" />
>>>>>> > +    </condition>
>>>>>> >   d: manually build the icu-3.4 library since no prebuilt library
>>>>>> package
>>>>>> > available
>>>>>> >   e: vmcore.xml
>>>>>> > +                               <include
>>>>>> > name="vmcore/src/util/mips/base_natives" if="is.mips32"/>
>>>>>> > +                               <include
>>>>>> name="port/src/encoder/mips"
>>>>>> > if="is.mips32"/>
>>>>>> > +                               <include
>>>>>> name="vmcore/src/lil/mips/include"
>>>>>> > if="is.mips32"/>
>>>>>> > ...................others minor fixes...........
>>>>>> > 3. after step 2, I finally can build the whole hdk(working_classlib,
>>>>>> > working_vm, working_jdktools), then I tried to run the
>>>>>> HelloWorld.java,
>>>>>> > however, I met segmentation fault at the very begging of the
>>>>>> launcher.
>>>>>> > I debug this problem, and the following is my finding now:
>>>>>> >   a. the gdb backtrace is:
>>>>>> > (gdb) bt
>>>>>> > #0  0x2aaf5164 in apr_initialize () at misc/unix/start.c:46
>>>>>> > #1  0x2aaebecc in hythread_lib_create (lib=0x2ab299b0) at
>>>>>> > /home/stw/harmony/harmony-nofetch/working_vm/vm/thread/src/thread_i\
>>>>>> > nit.c:176
>>>>>> > #2  0x2aaebe54 in hythread_library_init () at
>>>>>> >
>>>>>> /home/stw/harmony/harmony-nofetch/working_vm/vm/thread/src/thread_init.c:70
>>>>>> >    b. when I use disass under gdb, I found that one instruction
>>>>>> > in apr_initialize caused the problem:
>>>>>> >        0x2aaf5160 <apr_initialize+28>: lui     v0,0x5
>>>>>> >        0x2aaf5164 <apr_initialize+32>: lw      v1,-9760(v0)
>>>>>> >    c. then I suspect its apr's problem, so I rebuilt the apr
with
>>>>>> -O0, then
>>>>>> > first verify using the test/testall, all tests passed
>>>>>> >        I even execute the test/sockperf alone, it also pass,
note
>>>>>> that
>>>>>> > sockperf call apr_initialize in its main function, but no
>>>>>> segmentation
>>>>>> > fault,
>>>>>> >       so I assume apr has no problems.
>>>>>> >    d. then I rebuilt the hdk, but the segmentation problem still
>>>>>> exists.
>>>>>> >    e. finally I suspect that there may be some problem with
gp
>>>>>> issues, but
>>>>>> > I have no clues. When checking how the launcher is built, I
am
>>>>>> confused with
>>>>>> > libhythr.so, it seems that the launcher is first built under
>>>>>> > working_classlib, link with libhythr.so under
>>>>>> > working_classlib/modules/portlib/src/main/native/thread/, then
after
>>>>>> the
>>>>>> > launcher is copied into working_vm, it will be linked with
>>>>>> libhythr.so
>>>>>> > under working_vm/vm/thread/src/, is that right?
>>>>>> >       but I still can not figure out the root cause, can anyone
give
>>>>>> me
>>>>>> > some suggestions for this hard issue, or someone also experienced
>>>>>> similar
>>>>>> > issues before?
>>>>>> >
>>>>>> >
>>>>>> > the Summary:
>>>>>> >   1. no regression on X86_64 for the MIPS patch
>>>>>> >   2. buildable on MIPS for that patch
>>>>>> >   3. running time error(segmentation fault) at the very begging
of
>>>>>> the
>>>>>> > launcher on MIPS
>>>>>> >
>>>>>> >
>>>>>> > Thanks.
>>>>>> >
>>>>>> > Tianwei
>>>>>> > --
>>>>>> > Sheng, Tianwei
>>>>>> > Inst. of High Performance Computing
>>>>>> > Dept. of Computer Sci. & Tech.
>>>>>> > Tsinghua Univ.
>>>>>> >
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Sheng, Tianwei
>>>>> Inst. of High Performance Computing
>>>>> Dept. of Computer Sci. & Tech.
>>>>> Tsinghua Univ.
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Sheng, Tianwei
>>>> Inst. of High Performance Computing
>>>> Dept. of Computer Sci. & Tech.
>>>> Tsinghua Univ.
>>>>
>>>
>>>
>>>
>>> --
>>> Sheng, Tianwei
>>> Inst. of High Performance Computing
>>> Dept. of Computer Sci. & Tech.
>>> Tsinghua Univ.
>>>
>>
>>
>>
>> --
>> Sheng, Tianwei
>> Inst. of High Performance Computing
>> Dept. of Computer Sci. & Tech.
>> Tsinghua Univ.
>>
>
>
>
> --
> Sheng, Tianwei
> Inst. of High Performance Computing
> Dept. of Computer Sci. & Tech.
> Tsinghua Univ.
>



-- 
Sheng, Tianwei
Inst. of High Performance Computing
Dept. of Computer Sci. & Tech.
Tsinghua Univ.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message