Develop Reference

Understand the Garbage collector logs flutter

Here is the output of my logging of my flutter app :
Explicit concurrent copying GC freed 25188(844KB) AllocSpace objects, 1(20KB) LOS objects, 2% free, 301MB/309MB, paused 348us total 317.699ms
I would like to understand :
What does "LOS" mean ?
What is the "2% free" ? (The space that the garbage collector managed to free ? or the remaining RAM available ?)
What represents the 301MB and the 309MB ?
As i am using the flutter DevTools to look for memory, i am seeing very different numbers :
’
I have added the "Android" tag because i am running the app on Android 10 and i believe the answer would be the same for IOS.
Thanks in advance

This log messages are not coming from Flutter but Android itself. Based on the log format in your example I guess it is logging from ART (Android RunTime) and where the log format is described in details here the documentation: https://developer.android.com/studio/debug/am-logcat?hl=lt#ARTLogMessages
So to answer your questions:
What does "LOS" mean ?
Large Object Space
What is the "2% free" ? (The space that the garbage collector managed to free ? or the remaining RAM available ?). What represents the 301MB and the 309MB ?
From the linked documentation:
Heap stats
Percentage free and (number of live objects)/(total heap size).
So your current heap takes 309 MB memory, contains objects which takes 301 MB inside it. Which means 2% of the heap is free to be used.

Out of memory error android due to fragmentation after 20+days

I made a application that runs on a coffee machine.After 20+ days (can be 60+ days depending on use)
an OutOfMemoryError occurs:
java.lang.OutOfMemoryError: Failed to allocate a 604 byte allocation with 16777216 free bytes and 319MB until OOM; failed due to fragmentation (required continguous free 65536 bytes for a new buffer where largest contiguous free 53248 bytes)
My question is:
Is there a way to run a defragmentation on memory android application programmatically?
The time it takes should not be a issue because machine goes into standby or eco mode.
And what I see is that there is more than enough memory available.

Is there a way to run a defragmentation on memory android application programmatically?
No. On Android 5.0-7.1, the best thing that you can do is get out of the foreground, as ART's garbage collector will compact memory only when your app is in the background. On Android 8.0+, ART's garbage collector will compact memory even while you are in the foreground.
Beyond that, aim to start a fresh process once per week or something, so you get a fresh heap.

free memory reporting when running "shark evolution"

I'm getting this message:
I/Unity ( 8132): Phone Stats - System Memory Free = 2019 Cores 2 Rez 1920
when I try to run Shark Evolution on my Android-L system. Apparently, there isn't that much free memory. /proc/meminfo reports only about 500 MB free. Not sure how the game ends up getting this big number. Any thoughts?
Thanks

I think you should ask guys who wrote this game - what do they mean by this number... ;) This log print is done by the game scripts, not by the Unity engine itself.
The only Unity API I found that provide memory info is SystemInfo.systemMemorySize, and it says
This is the approximate amount of system memory in megabytes.
It returns total physical memory, not free memory. There can also be some plugin code behind that collects this number, or some magic, or... I wouldn't rely on this number until you really know what the game developers meant, and whether they really called systemMemorySize.

Android Dalvik VM Logcat

Can anyone explain the below Logcat message :
D/dalvikvm(4440): GC_EXTERNAL_ALLOC freed 338K, 47% free 6427K/11911K, external 20418K/22446K, paused 53ms
E/dalvikvm-heap(4440): 2519424-byte external allocation too large for this process.
D/dalvikvm(4440): GC_FOR_MALLOC freed <1K, 47% free 6427K/11911K, external 20398K/22446K, paused 40ms
E/GraphicsJNI(4440): VM won't let us allocate 2519424 bytes

In older versions of Android, certain bits of native framework code would tell the VM about native allocations. This "external allocation" mechanism was an ugly hack introduced so that native allocations would cause the Dalvik VM to do a garbage collection pass.
The basic problem was that the Java-language Bitmap object used native memory for the pixel storage. Because the managed-heap objects were tiny, and the native-heap objects were large, you could allocate tons of Bitmaps without causing a GC. This was causing apps to bloat up and the system to slow down.
So, "external allocations" were introduced. Whenever the pixel storage for a Bitmap was allocated on the native heap, an equal amount of memory was deducted from the managed heap. The idea is that, if your heap is filling up with no-longer-reference bitmaps, you'll run out of managed heap space and the GC will fire.
(Unfortunately the GC can't actually release the native storage -- you need to run a finalizer to do that, and finalizers run in a separate pass after the GC completes. For a while the native objects were also holding on to some additional managed-heap objects, so you'd have to GC + finalize + GC to actually clean everything up.)
My "favorite" part about external allocations is that the API was a simple "increase by N" / "decrease by N", which meant there was no way to associate the native heap with a managed heap object, or check for leaks. Because all of the information about the Bitmap was kept in the native object, you couldn't even guess at how much native storage was needed, so it was impossible to look at an hprof dump and figure out how much memory a Bitmap was actually using.
In Android 3.0 ("Honeycomb") the pixel storage was moved onto the managed heap, and the external allocation mechanism was removed.
So, what the log message in your question means is: some code, probably Bitmap, wanted to allocate 2.5MB of native heap, but that would exceed the VM's external allocation heap limit. You need to figure out what's eating up 20MB of external allocation storage and release some of it.
The only way to get information about external allocations is by watching the event log. A few years back I threw a script together (gclog.py -- was in AOSP dalvik/tools for a while). I have no idea if it will still do anything useful. I talk about how to use it in this old thread.

the log of GC on Android

i face a problem on understand the GC log.
Log: GC_EXTERNAL_ALLOC freed 82K, 48% free 2829K/5379K, external 1702K/2137K, paused 28ms
Anyone can explain the meaning of the log?
Thanks.

In this Google IO I once watched I believe the presenter (Patrick Dubroy) states the different logs, and their association: Google I/O: Memory Management for Android Apps
I hope this helps.

I don't think those log messages are documented.
If you're developing with Eclipse you are supposed to use DDMS perspective | Allocation Tracker to track your memory allocations.