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 -~----------~----~----~----~------~----~------~--~---
