Hi fadden, Thanks for your suggestions.
Sure I traced the String.equals and found that some codes call the implementation in String.java, while the test code of mine didn't call it. Then I followed your advice to trace the inline native implementation in dalvik/vm/InlineNative.c, luckily that it was called. Then I checked the code in InlineNative.c carefully. They are all correct. And then the __memcmp16() in my implementation. And finally I found that my __memcmp16() was wrong. In my implementation, I think that the third parameter "size_t count" is in byte-length. While by reading InlineNative.c I knowed that it is in short-length, but not byte- length. So my __memcmp16() return a wrong value to "pResult->i" when the two strings have the same length. And now by fixing __memcmp16(), the test code ran well and can return the correct result. Thanks fadden again. You know that my work is to porting Android to a new architecture different from arm and x86. So almost everything needs to be added for me, the toolchain, the kernel, the bionic C library, then the Dalvik VM. The problem of String.equals was caused by the bionic C library. And your advice helped me to locate and fix the issue. - Peter On 4月29日, 上午2时24分, fadden <fad...@android.com> wrote: > On Apr 27, 11:43 pm, Peter <jl...@ingenic.cn> wrote: > > > I ran these codes on the Android's emulator and they returned > > res1=false and res2=false. (They are correct) > > > But when I ran them on XBurst, they returned res1=true and res2=false. > > (They are wrong) > > The difference is that the wrong one was got when the Android runtime > > startuped and while the correct > > one is just running .jar file on the command shell with dalvikvm. > > > So I guessed this should be the Android runtime problem when using the > > generic C implementation of Dalvik VM. > > There might be something else at work, depending on how exactly you're > going about things. > > The optimizations performed by "dexopt" include a form of instruction > inlining. For a handful of methods, listed in the gDvmInlineOpsTable > in dalvik/vm/InlineNative.c, the method call is replaced with an > instruction that performs the desired action without any of the method > overhead. The actual implementation doesn't run any faster than a > method declared "native", but we can skip all of the stack frame prep > and other method call overhead, so it's useful for simple methods that > are called very frequently. > > Typically your String.equals() call will end up in > javaLangString_equals() in InlineNative.c. This may use an Android- > specific ARM "memcmp16" function, or do a simple iterative loop in C. > The result goes into "pResult->i", and the function returns "true" to > indicate that no exception was thrown. > > If for some reason "dexopt" didn't optimize the code that calls > String.equals(), you will call the implementation in String.java > (dalvik/libcore/luni/src/main/java/java/lang/String.java). > > I looked over the code and all of the implementations seem correct. > They all test the length before comparing characters, so I can see how > you could get the results you described above if one of the comparison > loops was broken. > > When invoking Dalvik from the command line, you can control which > interpreter runs with "-Xint"; use "-Xint:portable" or "-Xint:fast". > You can control DEX optimizations with -Xdexopt, e.g. -Xdexopt:none to > disable it. You can verify what it did by running "dexdump -d" on the > optimized file in /data/dalvik-cache. Note the file doesn't get > regenerated if it doesn't need to be, so remove the /data/dalvik-cache > entry before running dalvikvm with a different "-Xdexopt" option. --~--~---------~--~----~------------~-------~--~----~ unsubscribe: android-porting+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-porting -~----------~----~----~----~------~----~------~--~---
