Every Android app is spawned from a process called zygote. In this process we preload the most commonly used classes and resources. Those preloaded chunks of memory are shared until marked dirty.
On Fri, Jul 2, 2010 at 8:44 AM, Kostya Vasilyev <[email protected]> wrote: > Actually, the cause of infinite gc was in my code. Mea culpa. > > Regarding the X509 and HtmlParser object - the thing I would like to > understand is whether these are taking up space in my application's heap or > not. > > Java MAT says they do (using an hprof dump created in DDMS). > > Is this tool wrong? Are these objects perhaps allocated in memory pages > shared by all instances of Dalvik VM? I certainly hope so, but if anyone can > shed some light on this, it would be great. > > -- Kostya > > 02.07.2010 19:26, social hub пишет: > > >From what I have seen before > > 57 instances of "org.bouncycastle.jce.provider.X509CertificateObject", > loaded by "<system class loader>" occupy 268 096 (15,03%) bytes. These > instances are referenced from one instance of > "java.util.HashMap$HashMapEntry[]", loaded by "<system class loader>" > > I think these are from Android itself to validate the application and > resources during runtime. I may be mistaken. > If you create a simple app and run memory analyzer you will see these > things. > > regarding the endless logcat stream of mem free I am not sure whats > happening. > > if you are not getting OOM error then you should be doing a good job. > I have encountered one memory error which relates to handler in a looping > condition. During destroy the the handler has to be freed of messages and > set to null. I found this using MAT. > > --- > > On Fri, Jul 2, 2010 at 10:00 AM, Kostya Vasilyev <[email protected]> wrote: >> >> Hello, >> >> I ran into what seems to be a memory management issue in my app. >> >> After running for a while, dalvik gc is triggered, but never finishes. I >> get an endless stream of these messages in logcat: >> >> D/dalvikvm(24822): GC freed 22018 objects / 528920 bytes in 49ms >> D/dalvikvm(24822): GC freed 22018 objects / 528920 bytes in 50ms >> D/dalvikvm(24822): GC freed 22018 objects / 528920 bytes in 50ms >> D/dalvikvm(24822): GC freed 22018 objects / 528920 bytes in 49ms >> D/dalvikvm(24822): GC freed 22018 objects / 528920 bytes in 50ms >> >> The application's normal execution obvoiusly stops, and never resumes. >> >> This is the first issue - GC is quite normal, but it never completing is >> not. For some reason, the Java VM tries to free the same objects over and >> over again, but never actually frees them. >> >> The second issue is that I used hprof and Java MAT to analyze what's >> taking up memory space. The report listed three problems: >> >> - 7 742 instances of "java.lang.String", loaded by "<system class loader>" >> occupy 473 856 (26,56%) bytes >> >> This is normal, created by my code. I certainly have work to do, making my >> code more optimized. My code doesn't hold on to these strings, so assuming >> issue #1 can be avoided, they should GC quite nicely. >> >> The other two entries are: >> >> 57 instances of "org.bouncycastle.jce.provider.X509CertificateObject", >> loaded by "<system class loader>" occupy 268 096 (15,03%) bytes. These >> instances are referenced from one instance of >> "java.util.HashMap$HashMapEntry[]", loaded by "<system class loader>" >> >> 2 985 instances of "java.lang.Class", loaded by "<system class loader>" >> occupy 659 560 (36,97%) bytes. >> >> Biggest instances: >> >> class com.ibm.icu4jni.util.Resources$DefaultTimeZones @ >> 0x40178af0 - 145 952 (8,18%) bytes. >> class android.text.Html$HtmlParser @ 0x4006fd18 - 126 592 (7,10%) bytes. >> class org.apache.harmony.security.fortress.Services @ 0x400731b0 - 51 456 >> (2,88%) bytes. >> class android.content.res.Resources @ 0x4004e848 - 34 416 (1,93%) bytes. >> class android.text.AutoText @ 0x400f6260 - 28 776 (1,61%) bytes. >> >> My application does not use time zones (just whatever the default one is >> implicit), HTML parsing, or X509 certificates. Why are they combined taking >> almost a megabyte of memory? How can I avoid it? >> >> My code certainly need to be more memory-optimized, but uses only about >> half the amount of memory already allocated inside my app by things I do not >> use. >> >> I would be grateful for any suggestions. >> >> -- >> Kostya Vasilev -- WiFi Manager + pretty widget -- >> http://kmansoft.wordpress.com >> >> >> -- >> 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 > > -- > 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 > > -- > Kostya Vasilev -- WiFi Manager + pretty widget -- > http://kmansoft.wordpress.com > > -- > 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 -- Romain Guy Android framework engineer [email protected] Note: please don't send private questions to me, as I don't have time to provide private support. 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
