I have to run my android application which means am getting the following messages on my logcat window:
12:05:36.056: System_process I/ActivityManager(59): Displayed activity com.xmlparsing/.MainActivity: 581 ms (total 581 ms)
12:05:41.136: com.android.defcon D/dalvikvm(253): GC_EXPLICIT freed 152 objects / 11024 bytes in 60ms
12:05:46.126: com.svox.pico D/dalvikvm(264): GC_EXPLICIT freed 31 objects / 1512 bytes in 50ms
12:05:51.156: com.android.setting D/dalvikvm(125): GC_EXPLICIT freed 975 objects / 42392 bytes in 78ms
12:06:40.666: com.xmlparsing D/dalvikvm(1131): GC_FOR_MALLOC freed 3884 objects / 321368 bytes in 50ms
12:06:40.836: com.xmlparsing D/dalvikvm(1131): GC_FOR_MALLOC freed 3654 objects / 427296 bytes in 48ms
12:06:41.026: com.xmlparsing D/dalvikvm(1131): GC_FOR_MALLOC freed 4007 objects / 418288 bytes in 45ms
12:06:41.245: com.xmlparsing D/dalvikvm(1131): GC_FOR_MALLOC freed 4516 objects / 414608 bytes in 54ms
12:06:41.456: com.xmlparsing D/dalvikvm(1131): GC_FOR_MALLOC freed 4194 objects / 399504 bytes in 53ms
12:06:41.616: com.xmlparsing D/dalvikvm(1131): GC_FOR_MALLOC freed 3365 objects / 412104 bytes in 43ms
12:06:41.666: com.xmlparsing I/System.out(1131): category size6
12:06:41.666: com.xmlparsing I/System.out(1131): category name is---------------->Photos
Here my application package is com.xmlparsing.
But here other packages(com.android.defcon,com.svox.pico,com.android.settings) is running on starting.this packages only taking more time to reading(loading) the data.please check the time.my xml file is read within second.why that package is loading.how can i control it.please give me solution for these
Those packages are not running "on your app". Android supports multitasking, so it is possible to have more than one app alive at a time.
In any case, the LogCat you posted shows that it is simply a GC call, which means Android is trying to free up memory. There is nothing you can do to control this.
If you want to view LogCay messages from only your app, try filtering by process id.
What you're seeing are log messages from the different processes that are going through Garbage Collection (GC).
On any system, Android or otherwise, there will likely be multiple processes running at the same time. On Android, the processes will periodically go through Garbage Collection to free up memory and keep the system running well and within its constrained resources. This is expected behavior.
Related
I have a problem with using the QNetworkAccessManager in Qt 5.5 on android. Downloading a simple, small graphic file via http GET results in a lot of garbage collection calls and a lockup of the UI during that time. Subsequent GETs work flawlessly and without these GC calls. The code is as follows:
void DownloadManager::downloadFile(QUrl fromUrl, QString toFilePath) {
_currentFilePath = toFilePath;
QNetworkRequest request;
request.setUrl(fromUrl);
qDebug() << "before";
_currentReply = _mgr.get(request);
qDebug() << "after";
connect(_currentReply, SIGNAL(error(QNetworkReply::NetworkError)), this, SLOT(downloadError(QNetworkReply::NetworkError)));
connect(_currentReply, SIGNAL(downloadProgress(qint64, qint64)), this, SLOT(downloadProgress(qint64,qint64)));
connect(_currentReply, SIGNAL(finished()), this, SLOT(downloadFinished()));
}
DownloadManager is a custom QObject-derived class without any special features that are relevant to the get request. _mgr is a QNetworkAccessManager Object that's allocated during DownloadManagers cTor.
As you can see, this is just a textbook example of a get request, nothing too fancy about it. And as I said: it works, for the most part. Only the first get request ends up like this:
D/ .../downloadmanager.cpp:61 (void DownloadManager::downloadFile(QUrl, QString)): before
D/dalvikvm(13298): GC_CONCURRENT freed 2290K, 25% free 10911K/14407K, paused 2ms+3ms, total 29ms
D/dalvikvm(13298): GC_CONCURRENT freed 501K, 25% free 10884K/14407K, paused 13ms+2ms, total 35ms
D/dalvikvm(13298): GC_CONCURRENT freed 524K, 25% free 10892K/14407K, paused 12ms+3ms, total 36ms
D/dalvikvm(13298): WAIT_FOR_CONCURRENT_GC blocked 6ms
D/dalvikvm(13298): GC_CONCURRENT freed 537K, 25% free 10887K/14407K, paused 2ms+9ms, total 32ms
D/dalvikvm(13298): WAIT_FOR_CONCURRENT_GC blocked 14ms
D/dalvikvm(13298): GC_CONCURRENT freed 840K, 25% free 10899K/14407K, paused 12ms+3ms, total 38ms
D/dalvikvm(13298): WAIT_FOR_CONCURRENT_GC blocked 11ms
D/dalvikvm(13298): GC_CONCURRENT freed 1294K, 25% free 10901K/14407K, paused 2ms+2ms, total 27ms
D/dalvikvm(13298): WAIT_FOR_CONCURRENT_GC blocked 11ms
D/dalvikvm(13298): GC_CONCURRENT freed 1187K, 22% free 11330K/14407K, paused 2ms+2ms, total 30ms
D/dalvikvm(13298): WAIT_FOR_CONCURRENT_GC blocked 15ms
D/dalvikvm(13298): GC_CONCURRENT freed 1459K, 19% free 11919K/14535K, paused 13ms+4ms, total 64ms
D/dalvikvm(13298): WAIT_FOR_CONCURRENT_GC blocked 18ms
D/ .../downloadmanager.cpp:65 (void DownloadManager::downloadFile(QUrl, QString)): after
I simply don't understand what causes that much GC to happen - it takes about a full to one and a half seconds for everything to work out (for a download that should take a split-second and, moreover, be asynchronus and not locking up the UI).
Additional Information:
It is always only the first download that triggers this. Subsequent downloads, even for the exact same file, work flawlessly
It doesn't matter if there's a file at the exact location with the exact name or not. Downloading the file, deleting it, getting back into the application and redownloading it provides the same results - the first get is slow and has the GC, the second works perfectly fine.
I call all that from a QML File, that causes a singleton c++ object to call DownloadManager::downloadFile.
Other than the QML UI, nothing else is running within the application. No heavy data exchanges, no background loading on other threads, nothing.
I'd be thankful for any pointers towards solving this.
I didn't try on Android, but I had the same issue on Windows. Because those are the same symptoms, I would say this is likely the same reason, which is that the implementation is lazily loading some shared library on the first get() call. This is particularly true when using an encrypted connection; in my case I can see in Visual Studio that 19 DLLs are loaded on the first get() call.
One way to work around that is to pre-connect to the server using connectToHost or connectToHostEncrypted, depending on whether you are using an encrypted connection (e.g. HTTPS) or not. I am calling that at application startup, but anytime the UI is idle should be fine. Then subsequent get() calls will all have the same performance, including the first one, since the libraries have been loaded and the connection is already established. I am assuming that connecting to any server will load the libraries.
See https://forum.qt.io/topic/65201/qnetworkaccessmanager-first-get-very-slow/14 for details on the generic error (not specific to Android).
I'm getting way too many GC_FOR_ALLOC from the dalvikvm.
I'm getting XML from a REST service: in one activity I parse about 100 lines programatically(me) and in the other activity I use the SimpleXML to parse about 200 lines.
In the first one I get 50 GC_FOR_ALLOC.
In the second one I get like 300!! (I can't even post it all, the body makes 29579 characters and it's allowed only 30k)
I've searched and almost everyone complains about gc_for_"M"alloc and not gc_for_"A"lloc.
Is the SimpleXML the problem because the instances created?
I'll post the logcat dump by dalvikvm, maybe the values have some information.
Thank you very much for your help.
12-11 06:13:49.564: D/dalvikvm(6759): GC_FOR_ALLOC freed 362K, 13% free 4116K/4688K, paused 181ms, total 182ms
12-11 06:13:50.074: D/dalvikvm(6759): GC_FOR_ALLOC freed 303K, 13% free 4134K/4708K, paused 142ms, total 142ms
.... repeated many times .....
12-11 06:14:06.254: D/dalvikvm(6759): GC_FOR_ALLOC freed 73K, 13% free 4159K/4768K, paused 53ms, total 53ms
12-11 06:14:06.314: D/dalvikvm(6759): GC_FOR_ALLOC freed 103K, 13% free 4159K/4768K, paused 56ms, total 57ms
12-11 06:14:06.374: D/dalvikvm(6759): GC_FOR_ALLOC freed 29K, 12% free 4203K/4768K, paused 54ms, total 54ms
12-11 06:14:06.424: D/dalvikvm(6759): GC_FOR_ALLOC freed 73K, 13% fre
You can see the most-recently-allocated objects using the DDMS Allocation Tracker (memory debugging docs, old blog post, ddms docs). This will show you what's being allocated and give you a stack trace for the place where the allocation is being performed.
Another blog post describes MAT and other relevant tools, though heap-dump analysis is less useful for this sort of problem because it generally shows you the objects that haven't been freed, and you're more interested in the objects that are being freed.
In Android Dalvik VM, GC_FOR_ALLOC is inovked in object alloc step when dlmalloc footprint space is NOT enough for new or heap->bytesAllocated + n > hs->softLimit. You can set dalvik.system.setTargetHeapUtilization lower for more free heap space.
you can use MAT MAT tutorial
to find how many object are creating and garbage collected. so that youcan optimize your code
If you get that multiple GC_FOR_ALLOC while your app is lagging, there is a big possibility that the bug is in a loop. Check where the line of code starts to trigger the GC then start tracing the code from there. In my experience, I mistyped my inner loop iterator which causes the program to make an infinite loop. I created a bug like this:
for(int i=0; i<list.size(); i++) {
for(int j=i+1 j<list.size(); i++) {
// I mistyped the iterator of integer j with i
// making an infinite loop which triggered the GC.
//appears many times
}
}
I encounter the same problem today.
I find a not ended loop in my code such as while(i < xx), but I not implement the i++ statement in the while body.
So the messages like you meet appeared.
Check your code firstly please.
My log:
D/dalvikvm: GC_FOR_ALLOC freed 549K, 9% free 7878K/8596K, paused 30ms, total 34ms
...freed 539K, 9% free 7888K/8596K, paused 30ms, total 30ms
...freed 1856K, 21% free 8083K/10108K, paused 51ms, total 51ms
...freed 582K, 9% free 7845K/8596K, paused 38ms, total 38ms
Explain:
When your app get memory more limit per app. Dalvik/Ant call garbage collector.
What limits memory for your App decide Dalvik/Ant. As you see for my app Dalvik decide 8596K(double case) and 8083K(one case).
And limits change in runtime.
And you can not be sure when this happens. But you can reduce the likelihood. Decreasing the amount of memory that your application consumes.
PS: Decide when call GC teakes Dalvik/Ant. And you can not be sure when this happens. But you can reduce the likelihood. Decreasing the amount of memory that your application consumes.
PS: In "Monitor android" see tab "Monitors", graphics "Memory". And use buttons: "pause(enabled)", Initiate GC, "Dump Java Heap" "Start Alocation Tracking(very useful)". And use official guide for this:
https://developer.android.com/studio/profile/am-memory.html?utm_source=android-studio.
As far as I understand App must not stop/pause working or crashes when VM call GC.
Hi I try to develop a simple Android service application using Titanium by following their tutorial. It works well when the application is in foreground, but when I press back button it kills the app and my service is not running.
Below is the code I used and the log I got when the app enters background. Please let me know where I am going wrong. (I am using Titanium SDK 2.0.1.GA2 and Android SDK 2.2 with Android Runtime v8/Rhino].
My app.js file:
var intent = Titanium.Android.createServiceIntent( { url: 'logservice.js' } );
// Service should run its code every 10 seconds.
intent.putExtra('interval', 10000);
// A message that the service should 'echo'
intent.putExtra('message_to_echo', 'Titanium rocks!');
var service = Titanium.Android.createService(intent);
service.addEventListener('resume', function(e) {
Titanium.API.info('Service code resumes, iteration ' + e.iteration);
});
service.addEventListener('pause', function(e) {
Titanium.API.info('Service code pauses, iteration ' + e.iteration);
/* if (e.iteration === 3) {
Titanium.API.info('Service code has run 3 times, will now stop it.');
service.stop();
} */
});
service.start();
And my logservice.js file is:
var service = Titanium.Android.currentService;
var intent = service.intent;
var message = intent.getStringExtra("message_to_echo");
Titanium.API.info("Hello World! I am a Service. I have this to say: " + message);
I included that service tag in tiapp.xml
And this is the log I am getting when I press back button:
W/KeyCharacterMap( 322): No keyboard for id 0
W/KeyCharacterMap( 322): Using default keymap: /system/usr/keychars/qwerty.kcm.bin
E/TiBaseActivity( 322): (main) [62040,92891] Layout cleanup.
D/dalvikvm( 322): GC_FOR_MALLOC freed 9526 objects / 480272 bytes in 115ms
D/dalvikvm( 322): GC_FOR_MALLOC freed 12770 objects / 693152 bytes in 80ms
D/dalvikvm( 322): GC_FOR_MALLOC freed 8846 objects / 508872 bytes in 77ms
D/dalvikvm( 322): GC_FOR_MALLOC freed 8976 objects / 512112 bytes in 78ms
D/EventEmitter( 322): callHandler function not available for resume
W/TiAnalyticsSvc( 322): (Thread-15) [29966,122857] Analytics Service Started
I/TiAnalyticsSvc( 322): (Thread-15) [69,122926] Sending 1 analytics events.
D/dalvikvm( 322): GC_FOR_MALLOC freed 7386 objects / 436936 bytes in 87ms
D/NativeCrypto( 322): Freeing OpenSSL session
D/dalvikvm( 322): GC_FOR_MALLOC freed 1581 objects / 89648 bytes in 71ms
I/dalvikvm-heap( 322): Grow heap (frag case) to 3.588MB for 87396-byte allocation
D/dalvikvm( 322): GC_FOR_MALLOC freed 12 objects / 712 bytes in 76ms
D/dalvikvm( 322): GC_FOR_MALLOC freed 956 objects / 49400 bytes in 88ms
I/dalvikvm-heap( 322): Grow heap (frag case) to 3.624MB for 87396-byte allocation
D/dalvikvm( 322): GC_FOR_MALLOC freed 0 objects / 0 bytes in 75ms
W/TiAnalyticsSvc( 322): (Thread-15) [3772,126698] Stopping Analytics Service
D/SntpClient( 60): request time failed: java.net.SocketException: Address family not supported by protocol
I'm working on an android app which fall into an infinite loop of GC_FOR_MALLOC freed :
06-15 11:24:56.685: DEBUG/dalvikvm(118): GC_FOR_MALLOC freed 4136 objects / 374744 bytes in 66ms
06-15 11:24:59.176: DEBUG/dalvikvm(521): GC_FOR_MALLOC freed 9340 objects / 524152 bytes in 645ms
06-15 11:24:59.846: DEBUG/dalvikvm(521): GC_FOR_MALLOC freed 9344 objects / 524328 bytes in 149ms
06-15 11:25:01.535: DEBUG/dalvikvm(521): GC_FOR_MALLOC freed 9346 objects / 524448 bytes in 193ms
06-15 11:25:02.175: DEBUG/dalvikvm(521): GC_FOR_MALLOC freed 9344 objects / 524344 bytes in 126ms
The application read some jpeg image over a socket (dedicated thread) and display it in a imageView. The GC loop is bloking the image display.
Is there a solution to know what line or at least what part of the code is throwing the Garbage collection ?
Thanks
I'm not sure if you can access the VM and check why it is performing gc all the time, but gc is usually performed when there is a need for it. You should check what is using so much memory. It may be loading your image (is it a big image?) or perhaps it is something else in your app. Check this post on how to analyse your memory usage and while you are at it check for memory leaks.
I've been reading around and looking into touchEvents, mainly because my GC is exploding when there is a lengthy touch/slide event OR many touch events. If I do not touch the phone it simply idles as ~5 objects as you can see from the first few GC_EXPLICIT that I performed from DDMS. I then began to touch the screen and sliding around, and the objects shot up around 13513 objects and actually caused a GC_FOR_MALLOC that takes over 100ms. Here was my simple testing code, and below is the log of the dalvicvm tag. If you have documentation of workarounds or causes, or possibly even just another in-depth discussion of this I would greatly appreciate it! Cheers, and good luck on your own endeavors.
[code]
public class testClass extends Activity implements IOnSceneTouchListener{
int numberOfTouches = 0;
#Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
requestWindowFeature(Window.FEATURE_NO_TITLE);
setContentView(R.layout.main);
}
#Override
public boolean onSceneTouchEvent(Scene pScene, TouchEvent pSceneTouchEvent) {
numberOfTouches++;
return false;
}
}
[logcat]
06-28 15:24:55.317: DEBUG/dalvikvm(2501): GC_EXPLICIT freed 5 objects / 128 bytes in 53ms
06-28 15:24:55.903: DEBUG/dalvikvm(2501): GC_EXPLICIT freed 5 objects / 136 bytes in 59ms
06-28 15:24:56.708: DEBUG/dalvikvm(2501): GC_EXPLICIT freed 5 objects / 128 bytes in 59ms
06-28 15:25:06.614: DEBUG/dalvikvm(2501): GC_EXPLICIT freed 6 objects / 168 bytes in 58ms
06-28 15:25:09.833: DEBUG/dalvikvm(2501): GC_EXPLICIT freed 7 objects / 192 bytes in 65ms
06-28 15:25:14.270: DEBUG/dalvikvm(2501): GC_EXPLICIT freed 8 objects / 232 bytes in 59ms
06-28 15:25:18.294: DEBUG/dalvikvm(2501): GC_EXPLICIT freed 6 objects / 160 bytes in 59ms
06-28 15:25:33.942: DEBUG/dalvikvm(1103): GC_FOR_MALLOC freed 13513 objects / 1403264 bytes in 121ms
06-28 15:26:53.684: DEBUG/dalvikvm(2139): GC_EXPLICIT freed 140 objects / 6960 bytes in 99ms
06-28 15:26:58.731: DEBUG/dalvikvm(1215): GC_EXPLICIT freed 668 objects / 71136 bytes in 117ms
06-28 15:27:31.637: DEBUG/dalvikvm(1103): GC_FOR_MALLOC freed 13962 objects / 1504296 bytes in 122ms
06-28 15:27:44.723: DEBUG/dalvikvm(2501): GC_EXPLICIT freed 63 objects / 2152 bytes in 59ms
06-28 15:27:46.676: DEBUG/dalvikvm(2501): GC_EXPLICIT freed 5 objects / 128 bytes in 65ms
06-28 15:27:47.238: DEBUG/dalvikvm(2501): GC_EXPLICIT freed 5 objects / 128 bytes in 58ms
I've yet to actually solve the problem but have stumbled across this great article on this exact problem: Android Touch Problems
[edit]
as stracka said, it's most likely due to flooding. My real issue is however with the allocations that are being made on each event? Is there a way to reuse these events/objects to limit allocations due to touch?
I'm currently using andEngine, and the touchEvents are pooled so there should be at most ~5 ever allocated from scratch; otherwise they just reuse don't they?
Thanks for any ideas....
Are you using an older version of Android? I was just reading about the "touch event flood" problem on Android 1.5 in Beginning Android Games. The author's workaround was to put the UI thread to sleep briefly in his onTouch() handler, to limit the number of events received. I don't know how viable that solution is, or if would be of any use to you; the pertinent page from the book can be found here:
Beginning Android Games, page 131
#Override
public boolean onTouchEvent(MotionEvent event) {
numberOfTouches++;
//events can be handled as well.
switch (event.getAction()) {
case MotionEvent.ACTION_DOWN:
invalidate();
break;
case MotionEvent.ACTION_MOVE:
invalidate();
break;
case MotionEvent.ACTION_UP:
invalidate();
break;
}
return true;
}
This goes light on GC and mallocs. This is the override method of a View.
Try it and reply..
android.view.View.onTouchEvent(MotionEvent event)
Reference:
http://developer.android.com/reference/android/view/View.html#onTouchEvent%28android.view.MotionEvent%29