Thanks for the link, I'll look into replacing the Protocol Buffers I use with that one. I'm assuming messages from the two are compatible, seeing as how that is the point of Protocol Buffers. :)
On Jul 23, 2:52 am, Dianne Hackborn <[email protected]> wrote: > You should consider using the MIDP protobuf code, which is what is used by > various Google apps: > > http://android.git.kernel.org/?p=platform/external/protobuf.git;a=tre... > > This is much more appropriate for Android. > > (Note this this is not part of the platform, so you will want to link it > into your app in a different namespace.) > > > > > > On Thu, Jul 23, 2009 at 2:30 AM, Micah <[email protected]> wrote: > > > It takes 20 seconds to load the test case class on an ADP1. :( If > > anyone has any ideas I'm open to trying things out or giving out the > > test case source code to look at. I don't know what Protocol Buffers > > does that is causing this, but if I'm not mistaken Protocol Buffers > > are used internally by the OS so my thought is that someone somewhere > > knows the answer. > > > On Jul 22, 2:05 pm, Micah <[email protected]> wrote: > > > Unfortunately, this doesn't seem to fully resolve my issue. I have > > > created a very simple repro case that causes the stall to occur (let > > > me know if anyone wants the source / APK). In the test, it will > > > eventually finish but it takes ~10 seconds just to make the call: > > > > Class.forName("com.zoltu.AndroidTest.Messages.Sample") > > > > On the plus side, the sample code isn't deadlocking, but it looks like > > > I'll still need to test on a physical device to see if it takes a > > > noticeable amount of time there like on the VM. > > > > On Jul 22, 10:49 am, fadden <[email protected]> wrote: > > > > > On Jul 21, 10:56 pm, fadden <[email protected]> wrote: > > > > > > The bug is that, while generating the list of declared methods, the > > VM > > > > > would initialize classes found in method arguments. Those classes > > > > > shouldn't be getting initialized at that point, and initialization > > > > > ordering problems ensue. > > > > > I got a copy of the APK (thanks!) and poked at it. I believe this is > > > > the same bug. > > > > > When the app launch stalled a sent the process a "kill -3" and pulled > > > > the stack trace out of /data/anr/traces.txt. The two interesting > > > > threads are: > > > > > "main" prio=5 tid=3 WAIT > > > > | group="main" sCount=1 dsCount=0 s=N obj=0x4001d520 self=0xbc60 > > > > | sysTid=1086 nice=0 sched=0/0 handle=-1343996920 > > > > at java.lang.Class.getDeclaredMethods(Native Method) > > > > - waiting on <0x1a8598> (a java.lang.Class) > > > > at java.lang.ClassCache.getDeclaredPublicMethods(ClassCache.java: > > > > 166) > > > > at java.lang.ClassCache.getDeclaredMethods(ClassCache.java:179) > > > > at java.lang.ClassCache.findAllMethods(ClassCache.java:249) > > > > at java.lang.ClassCache.getFullListOfMethods(ClassCache.java:223) > > > > at java.lang.ClassCache.getAllPublicMethods(ClassCache.java:204) > > > > at java.lang.Class.getMethod(Class.java:1006) > > > > at com.google.protobuf.GeneratedMessage.getMethodOrDie > > > > (GeneratedMessage.java:900) > > > > ... > > > > > "Graphics" prio=5 tid=19 WAIT > > > > | group="main" sCount=1 dsCount=0 s=N obj=0x43748ef8 self=0x1a4878 > > > > | sysTid=1094 nice=0 sched=0/0 handle=1722776 > > > > at com.ZZZ.Level$Map.<clinit>(Level.java:~1978) > > > > - waiting on <0x146768> (a java.lang.Class) > > > > at com.ZZZ.Level$LoadedAnnouncement.<init>(Level.java:-1) > > > > at com.ZZZ.Level$LoadedAnnouncement.<clinit>(Level.java:2586) > > > > at java.lang.Class.getDeclaredMethods(Native Method) > > > > at java.lang.ClassCache.getDeclaredPublicMethods(ClassCache.java: > > > > 166) > > > > ... > > > > > The're both under getDeclaredMethods, and they're both waiting on a > > > > Class object monitor (but not the same class). The Graphics thread is > > > > doing a couple layers of class initialization that it shouldn't be > > > > doing at that point. It's possible we've deadlocked on class init. > > > > > I tried it twice and ended up in the exact same place both times. > > > > With the bug fix in place it started up every time. > > > > > This problem will go away in a future release, but for now you can > > > > work around it by forcing initialization to happen earlier. The > > > > easiest way to do this is to call Class.forName(String className) > > > > early in the app start sequence. Start with Level$Map and Level > > > > $LoadedAnnouncement and see if that cures it. > > > > > For anyone building their own VM, you can see the patch inhttp:// > > code.google.com/p/android/issues/detail?id=3005. > > -- > Dianne Hackborn > Android framework engineer > [email protected] > > Note: please don't send private questions to me, as I don't have time to > provide private support, and so won't reply to such e-mails. All such > questions should be posted on public forums, where I and others can see and > answer them. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
