Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>First of all, are you running on the emulator? Because your heap size seems a bit too small. From my calculation you're crashing after about a total of 11MB total use (dalvik+native) and that's very little. Just to verify, do you have a line similar to this after your crash? </p> <pre><code>08-22 18:16:24.209: I/dalvikvm-heap(471): Clamp target GC heap from 24.610MB to 24.000MB </code></pre> <p>The max heap size (dalvik+native) is different between devices. The minimum is 16MB and the larger your screen resolution, the larger it is. Devices of 480x800 normally have above 32MB. You can control the heap size in your AVD settings of the emulator, make sure it's big enough to reflect a real device.</p> <p>Regarding your question, you're not supposed to defray the heap yourself. The VM does that automatically. It is true that the whole native heap mess makes it harder for the GC to estimate problems so you'll get a few OutOfMemoryErrors which you can probably avoid by manually running the GC before large allocations.</p> <p>More specifically, your large allocations happen when bitmaps are parsed (during calls like <code>BitmapFactory.decodeXXX()</code>). From my experience it actually helps to run <code>System.gc()</code> before them. You only need to do this on pre Honeycomb devices.</p> <p>Another tip is to free the native allocations as soon as possible. The pixels of your bitmaps are found in the native heap. They are freed only on the bitmaps finalizer, which as you know takes ages to run. This memory will only be freed after several runs of the system GC. This is why it's recommended to free it yourself manually. As soon as you're done with any bitmap, call <code>Bitmap.recycle()</code> to free its native memory immediately.</p>
    singulars
    1. This table or related slice is empty.
    1. PODefrag/decrease heap size on pre honeycomb
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. UStalkol
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. COI'm running on real 2.3 devices (e.g. Droid 2) so raising heap size isn't an option. All bitmap loads are wrapped with try/catch(OOM) and in the catch I call System.gc() and try again. But that doesn't seem to do anything. Unfortunately the VM doesn't defrag the heap automatically and shrinks it appropriately. That's why the native heap never gets enough memory because the Dalvik heap eats up all the resources on startup. This dual heap solution is incredibly frustrating I don't understand why this was implemented this way to begin with
      singulars
      1. PO
      1. USNeiti01
    2. COInstead of try catch and only on OOM do GC, on 2.x devices I always (!) do a GC before any bitmap decode. Try this please. Performance comes 2nd to crashes.. and if later we will want to reduce the number of GC we can check for low memory conditions manually by query of free heap size
      singulars
      1. PO
      1. UStalkol
    3. COWorking on real devices, really?? Help we understand the thing that's not adding up then. The numbers in your log don't add up, the problem I've always experienced was with the actual heap usage (the first number of the pair) not total heap size (the second). Can you provide the full log of the crash including the CLAMP line? We'll get to the bottom of this
      singulars
      1. PO
      1. UStalkol
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload