PATRICK DUBROY: Hi everybody, my name's Patrick Dubroy and
today I'm going to talk to you about memory
management for Android.
So I'm really happy to see so many people here who care
about memory management, especially near
the end of the day.
So let's get started.
So I'm sure you all remember this device.
This is the T-Mobile G1.
Hugo talked about it in the keynote yesterday.
It was released about two and a half years ago.
So, is there anybody here who actually developed on the G1?
All right, impressive.
That's about maybe 40% of the room.
So you may remember that the G1 came with 192
megabytes of RAM.
And in fact, most of that was used up by the system.
There wasn't a whole lot left over for apps.
Fast forward a few years later, we have the Motorola
Zoom released just a couple of months ago.
The Zoom comes with a gigabyte of RAM.
Now some people might hear this and think, OK, my
troubles are over.
I never have to worry about memory management again.
And of course, given that we have a whole room here, you
guys are all smart people and you realize
that that's not true.
And there are a couple of reasons for this.
First of all, the Zoom has six and a half times the
resolution that the G1 had.
So you've got six and a half times as
many pixels on screen.
That means you're probably going to
need to use more memory.
You got more bitmaps for example.
The other thing is that on tablets, you really want to
create a new kind of application.
You know, the rich, immersive applications, like this
YouTube app, for example.
These are going to take a lot of memory.
There's tons of bitmaps in here.
Those use up a lot of memory.
Also, the Zoom we're talking about a pretty new device.
This is basically bleeding edge hardware.
Most your customers are not going to be using something
that's only two months old.
So of course, you want to support people who are using
older hardware as well.
Finally, maybe you're all familiar with Parkinson's Law,
which says that work always take as much time as you have.
And really, it's kind of the same for software.
So, no matter how much memory you have, you're going to find
a way to use it and wish you had just a little bit more.
What I want to talk about today are basically two
different things.
First of all, I want to cover some of the changes that we've
made in Gingerbread and Honeycomb that affect how your
app uses memory.
That's your cameo.
All right, so as I was saying, there are two different things
I want to cover today.
So first of all, I want to talk about some of the changes
we've made in Gingerbread and Honeycomb that affect how your
apps use memory.
And basically, memory management in general.
In the second half of the talk I want to talk about some
tools you can use to better understand how your app is
using memory.
And if you have memory leaks, how you can figure out where
those memory leaks are.
So just to set expectations for this talk, I'm going to
make them some assumptions about the stuff you've done
and it'll really help you get the most out of this if you're
familiar with these concepts.
So I'm hoping that you've all written Android apps before.
And it looked like about half the room had developed on the
G1, so that's probably true.
I hope that most of you have heard of the Dalvik heap.
You have a basic idea of what I'm talking about when I talk
about heap memory.
I'm sure you're familiar with the garbage collector.
You have a basic idea hopefully of what garbage
collection is and how it works.
And probably, most of you have seen an OutOfMememoryError
before and you have a basic idea of why you get it and
what you can do to deal with it.
So first, let's talk about heap size.
So you may know that in Android, there's a hard limit
on your application's heap size.
And there's a couple reasons for this.
So first of all, one of the great features of Android is
that it has full multitasking.
So you actually have multiple programs running at once.
And so obviously, each one can't use all of
your devices memory.
We also don't want a runaway app to just start getting
bigger and bigger and bloating the entire system.
You always want your dialer to work, your launcher t work,
that sort of thing.
So there's this hard limit on heap size and if your
application needs to allocate more memory and you've gone up
to that heap size limit already, then you're basically
going to get an out of memory error.
So this heap size limit is device dependent.
It's changed a lot over the years.
On the G1 it was 16 megabytes.
On the Zoom it's now 48 megabytes.
So it's a little bit bigger.
If you're writing an app and you want to know, OK, how much
heap space do I have available?
You know, maybe you want to decide how much stuff to keep
in a cache for example.
There's a method you can use in ActivityManager,
getMemoryClass that will return an integer value in
megabytes, which is your heap size.
Now these limits were designed assuming that you know almost
any app that you would want to build on Android should be
able to fit under these limits.
Of course, there are some apps that are
really memory intensive.
And as I said, on the tablet, we really want to build almost
a new class of application.
It's quite a different than the kind of things you were
building on phones.
So we thought, if someone wants to build an image
editor, for example, on the Zoom, they should
be able to do that.
But an image editor's a really memory intensive application.
It's unlikely that you could build a good one that used
less than 48 megabytes of heap.
So in Honeycomb we've added a new option that allows
applications like this to get a larger heap size.
Basically, , you can put something in your
AndroidManifest, largeHeap equals true.
And that will allow your application to use more heap.
And similarly, there's a method you can use to
determine how much memory you have available to you.
The ActivityManager getLargeMemoryClass method
again, will return an integer value of this large heap size.
Now before we go any further, I want to give
a big warning here.
You know, this is not something you should be doing
just because you got an out of memory error, or you think
that your app deserves a bigger heap.
You're not going to be doing yourself any favors because
your app is going to perform more poorly because bigger
heap means you're going to spend more time at garbage
collection.
Also, your users are probably going to notice because all
their other apps are getting kicked out of memory.
It's really something you want to reserve for when you really
understand OK, I'm using tons of memory and I know exactly
why I'm using that memory, and I really
need to use that memory.
That's the only time that you should be using this large
heap option.
So I mentioned garbage collection.
And that it takes longer when you have a bigger heap.
Let's talk a little bit about garbage collection.
So I just want to go through a quick explanation here of what
[INAUDIBLE]
garbage collection is doing.
So basically, you have a set of objects.
First of all, let's say these blue objects here, these are
the objects in your heap.
And they form a kind of graph.
They've got references to each other.
Some of those objects are alive, some of them are not
used anymore.
So what the GC does is it starts from a set of objects
that we call the roots.
These are the objects that the GC knows is alive.
For example, variables that are alive on a thread stack, J
and I global references, we treat objects in the zygote as
heap, or as roots as well.
So basically, the GC starts with those objects and starts
visiting the other objects.
And basically, traversing through the whole graph to
find out which objects are referenced directly or
indirectly from the GC roots.
At the end of this process, you've got some objects left
over, which the GC never visited.
Those are your garbage.
They can be collected.
So it's a pretty simple concept.
And you can see why when I said that you have bigger
heaps you're going to have larger pause times.
Because the garbage collector basically has to traverse your
entire live set of objects.
If you're using say the large heap option and you've got 256
megs of heap, well, that's a lot of memory for the garbage
collector to walk over.
You're going to see longer pause times with that.
We have some good news though.
In Gingerbread, there have been some great changes to the
garbage collector that make things a lot better.
So in Gingerbre--
sorry, pre-Gingerbread, the state of the garbage collector
was that we had to stop the world collector.
So what this means is that basically, when a garbage
collection is in progress, your application is stopped.
All your application threads are completely stopped while
the collection is proceeding.
This is a pretty standard things.
These pauses generally tend to be pretty short.
What we found was that pause times as heaps were getting
bigger, these were getting to be a little bit too long.
So we were seeing stuff up 50 to 100 milliseconds.
And if you're trying to build a really responsive app that
kind of pause time is not really acceptable.
So in Gingerbread, we now have a
concurrent garbage collector.
It does most of its work concurrently, which means that
your application is not stopped for the duration of
the garbage collection.
Basically, we have another thread that's running at the
same time as your application that can perform garbage
collection work.
You'll see basically two short pauses.
One at the beginning of a collection and
one near the end.
But these pause times are going to be much, much lower.
Usually you'll see two, three, four, or five milliseconds for
your pause time.
So that's a significant improvement.
Pause times about 10% of what they used to be.
So that's a really good change that we have in Gingerbread.
Now if you're building memory heavy apps, there's a good
chance you're using a lot of bitmaps.
We found that in a lot of apps you have maybe 50 or 75% of
your heap is taken up by bitmaps.
And in Honeycomb because you're going to be developing
on tablets, this gets even worse.
Because your images are bigger to fill the screen.
So before Honeycomb, the way we managed bitmaps was this.
So the blue area up here is the Dalvik heap and this
yellow object is a bitmap object.
Now bitmap objects are always the same size in the heap no
matter what their resolution is.
The backing memory for the bitmap is actually stored in
another object.
So the pixel data is stored separately.
Now before Honeycomb what we did was this pixel data was
actually native memory.
It was allocated using malloc outside the Dalvik heap.
And this had a few consequences.
If you wanted to free this memory you could either call
recycle, which would free the memory synchronously.
But if you didn't call recycle and you were waiting for your
bitmap to get garbage collected, we had to rely on
the finalizer to free the backing memory for the bitmap.
And if you're familiar with finalization, you probably
know that it's an inherently unreliable process.
Just by its nature it takes several collections, usually
for finalization to complete.
So this can cause problems with bitmap heavy app as you
had to wait for several garbage collections before
your pixel data was reclaimed.
And this could be a lot of memory because bitmap pixel
data is quite a significant portion of the heap.
This also made things harder to debug.
If you were using standard memory analysis tools like the
Eclipse Memory Analyzer, it couldn't actually see this
native memory.
You would see this tiny bitmap object.
Sure, but that doesn't tell you very much.
You don't mind if you have a 10 by 10 bitmap.
But if you have a 512 by 512 bitmap it's a big difference.
Finally, the other problem that we had with this approach
was that it required full stop the world garbage collections
in order to reclaim the backing memory, assuming that
you didn't call recycle, that is.
The good news is in Honeycomb we've changed
the way this works.
And the bitmap pixel data is now allocated inside the
Dalvik heap.
So this means it can be freed synchronously by the GC on the
same cycle that your bitmap gets collected.
It's also easier to debug because you can see this
backing memory in standard analysis tools like Eclipse
Memory Analyzer.
And I'm going to do a demo in a few minutes and you'll see
really, how much more useful this is when you
can see that memory.
Finally, this strategy is more amenable to concurrent and
partial garbage collections, which means we can generally
keep those pause times down.
So those are the two biggest changes that we've introduced
in Gingerbread and Honeycomb that affect how
your apps use memory.
And now I want to dive in to some tools that you can use to
better understand how much memory your app's using.
And if you have memory leaks, better understanding where
those leaks are and generally, how your app is using memory.
The most basic tool you can use for understanding your
apps memory usage is to look at your log messages.
So these are the log messages that you see in DDMS in the
log cat view.
You can also see them at the command line
using ADB log cat.
And every time a garbage collection happens in your
process, you're going to see a message that looks something
like this one.
And I just want to go through the different parts of this
message, so you can better understand what
it's telling you.
The first thing we have is the reason for the garbage
collection.
Kind of what triggered it and what kind of collection is it.
This one here was a concurrent collection.
So a concurrent collection is triggered by basically, as
your heap starts to fill up, we kick off our concurrent
garbage collection so that it can hopefully complete before
your heap gets full.
Other kinds of collections that you'll
see in the log messages.
GC for malloc is one of them.
That's what happens when say, we didn't complete the
concurrent collection in time and your application had to
allocate more memory.
The heap was full, so we had to stop and do a garbage
collection.
You'll see GC external alloc, which is for externally
allocated memory, like the bitmap pixel
data which I mentioned.
It's also used for NIO direct byte buffers.
Now this external memory as I mentioned, has
gone away in Honeycomb.
Basically everything is allocated inside
the Dalvik heap now.
So you won't see this in your log messages in
Honeycomb and later.
You'll also see a message if you do an HPROF, if you create
an HPROF profile.
And finally, the last one I want to
mention is GC explicit.
You'll see this generally when you're calling system.gc,
which is something that you know you really
should avoid doing.
In general, you should trust in the garbage collector.
We've got some information also about the amount of
memory that was freed on this collection.
There's some statistics about the heap.
So the heap in this case, was 65% free after
the collection completed.
There's about three and a half megs of live objects and the
total heap size here is listed as well.
It's almost 10 megs, 9,991 K.
There's some information about externally allocated memory,
which is the bitmap pixel data and also,
NIO direct byte buffers.
The two numbers here, the first number is the amount of
external memory that your app has allocated.
The second number is a sort of soft limit.
When you've allocated that much memory, we're going to
kick off a GC.
Finally, you'll see the pause times for that collection.
And this is where you're going to see the effect
of your heap size.
Larger heaps are going to have larger pause times.
The good news is for a concurrent collection, you're
going to see these pause times generally pretty low.
Concurrent collections are going to show two pause times.
There's one short pause at the beginning of the collection
and one most of the way through.
Non-concurrent collections you'll see a single pause
time, and this is generally going to
be quite a bit higher.
So looking at your log messages is a really basic way
to understand how much memory your app is using.
But it doesn't really tell you, where am
I using that memory?
What objects are using this memory?
And the best way to do that is using heap dumps.
So a heap dump is basically a binary file that contains
information about all of the objects in your heap.
You can create a heap dump using DDMS by clicking on the
icon, this somewhat cryptic icon.
I think [INAUDIBLE]
mentioned it in the previous talk.
There's also an API for creating heap dumps.
In general, I find using DDMS is fine.
There are times when you want to create a heap dump at a
very, very specific point in time.
Maybe when you're trying to track down a memory leak.
So it can be helpful to use that API.
You may need to convert the heap dump to the standard
HPROF format.
You'll only need to do that if you're using the standalone
version of DDMS. If you're using the Eclipse plug-in, the
ADT plug-in, it will automatically convert it.
But the conversion is pretty simple.
There's a tool in the Android SDK, which you
can use to do it.
And after you've converted it to the standard HPROF format,
you can analyze it with standard heap analysis tools,
like MAT or jhat.
And I'm going to show an example of MAT, which is the
shorter way of saying the Eclipse Memory Analyzer.
And before I jump into the demo, I want to talk about
memory leaks.
So there's kind of a misconception that in a
managed run time, you can't have memory leaks.
And I'm sure you guys know that's not true.
Having a garbage collector does not prevent memory leaks.
A memory leak in a managed run time is a little bit different
though, than a memory leak in C or C++.
Basically, a leak is when you have a reference to an unused
object that's preventing that object from
being garbage collected.
And sometimes you can have a reference to a single object,
but that object points to a bunch of other objects.
And basically, that single reference is preventing a
large group of objects from being collected.
One thing to watch out for in Android.
I see people sometimes and I've done this myself,
accidentally create a memory leak by holding a long lived
reference to an activity.
So you need to be really careful with that and maybe
it's you're holding a reference to the context and
that's what happens.
You can also do it by keeping a long lived reference to a
view or to a drawable, because these will also hold a
reference to the activity that they were originally in.
And the reason that this is a problem, the reason this
causes a memory leak is this.
So you've got your activity, it contains a view group, a
linear layout or something, and it contains some views.
And we've got a reference from the framework to the currently
visible activity.
But in Android, when you have a rotation event, so you
rotate your device, what we do is actually build up a new
view hierarchy because you need to load new resources,
you may have a brand new layout for landscape or
portrait, you may have differently
sized icons or bitmaps.
And then we basically remove the reference to the old view
hierarchy and point to the new one.
And the idea is that this old view hierarchy sure get
garbage collected.
But if you're holding a reference to that, you're
going to prevent it from getting garbage collected.
And that's why it's a problem to hold the long lived
reference to an activity or even to a view because in
fact, the arrows connecting these objects should be going
in both directions.
Because you've got pointers all the way up.
So if you do have a memory leak, a really good way to
figure out where it is is using the
Eclipse Memory Analyzer.
I'm going to do a demo of that, but I want to first
cover some of the concepts behind the Memory Analyzer, so
that when I do the demo you'll better understand what I'm
showing you.
So the Eclipse Memory Analyzer can be downloaded from the
eclipse.org site.
It comes in a couple of flavors.
There's an Eclipse plug-in version, there's also a
standalone version.
I'm going to be demonstrating the standalone version.
I just personally prefer not to have Eclipse have all these
different plug-ins.
I kind of like to keep things a little bit separate.
But they're basically the same.
Now, Memory Analyzer has some important concepts that
you'll see a lot.
It talks about shallow heap and retained heap.
So the shallow heap of an object is just how large is
this object, it's size and bytes.
It's really simple.
So let's say that all of these objects are 100 bytes.
So they're shallow heap is 100 bytes.
It's easy.
The retained heap is something different.
Basically, the retained heap says, if I have an object here
and I were to free this object, what other objects is
it pointing to?
And could those be freed at the same time?
And so you calculate the retained heap in terms of,
what is the total size of objects that could be freed by
freeing this one object?
So maybe it's best to understand with an example.
So this object down on the right-hand side in yellow,
this guy doesn't point to any other objects.
So his retained size is pretty easy to calculate.
His retained heap is 100.
This guy on top, he has a pointer to one other object.
But he's not holding that object alive.
There are other pointers to that same object.
So this guy's retained heap is also just 100 bytes.
Because if we were to remove this object, it's not going to
free up any other objects.
The object down at the end however, it's basically
keeping all the other objects alive.
So its retained heap is 400 because if we could free that
object, we could free all the other objects well, on this
slide anyway.
So you might be wondering, how do you go about calculating
the retain heap?
So you're going to see this in Memory Analyzer.
And actually, knowing how it calculates the retained heap
is quite useful.
So the Memory Analyzer uses a concept called
the denominator tree.
This is a concept from graph theory.
Basically, if you have a node A and a node B, A is said to
be the dominator of B if every path to B goes through A.
And so you might see how that could help us figure out what
the retained heap of an object is.
So another example here.
So let's start with A.
It's kind of the root.
B and C are only accessible through A.
So it's pretty straightforward.
They're children of A and the dominator tree.
E is also only accessible through C.
So it's a child of C in the dominator tree.
D is a little bit interesting here.
D can be accessed through B or C, but A is on
every path to D.
So that means that A is the parent of D and
the dominator tree.
And now you're going to see this dominator tree concept
also pop up in Memory Analyzer in its UI.
And it can be really helpful for
tracking down memory leaks.
So let's jump in and do a demo of debugging and
memory leak with MAT.
So what I'm going to use for this demo is the Honeycomb
gallery's sample application.
It's a simple application that comes with the Android SDK the
basically just demonstrates some of
the features of Honeycomb.
And really, all it is is a little app the lets you page
through some photos.
Pretty simple.
Now I've done something kind of naughty here.
I've introduced a memory leak into this application.
And I'll show you how I've done that.
Sorry, I better switch to the slides again.
So you'll see here I have the source code, an excerpt of the
source code from the activity.
And so what I've done here is I've introduced this inner
class called leaky.
And this is not a static inner class.
So you may know that if you create a non-static inner
class, it actually keeps a reference to
the enclosing object.
And this is because from a non-static inner class, you
can actually refer to the instance variables of the
enclosing object.
So it's going to retain a reference to
the activity here.
That's fine as long as this object doesn't live longer
than the activity.
But I've got this static field and statics live longer than
any particular instance.
And in my on create method, what I've done is instantiated
the leaky object and stored it into the static field.
So if you want to be able to visualize this, I basically
got my view hierarchy that starts with the main activity.
I've instantiated this leaky object and he has a reference
to the main activity because that was its enclosing class.
Finally, I have the main activity class, which is
conceptually a different area of memory than
any particular instance.
And there's a static variable pointing to the leaky object.
So maybe you can see how this is going to cause a memory
leak when I rotate the screen.
So let's jump in and take a look at this memory leak.
So if you want to figure out whether you have a memory
leak, one of the easiest ways is to just kind of look at
your log messages.
So I'm just going to do that.
I'm going to do it at the command line.
I can just type ADB log cat.
And I want to restrict it to the particular process that
I've got running here.
I don't want to see all of the log messages on the system.
So I'm just going to grab on the process ID.
There we see a bunch a log messages, including some
garbage collection messages.
And the number you want to look at is basically the first
number here in the 9805K.
The first number in your heap size.
This is the amount of live objects in the system.
And if you're looking for a memory leak, that's what you
want to look at.
So I'm going to flip through some of the photos here.
And you'll see that that number stays pretty constant.
We're up to 9872.
But basically, the heap usage is pretty constant.
Now when I rotate this device, we're going to be a bunch of
garbage collections happen.
That heap usage goes up and it doesn't go down again.
So we're now up to 12 megs of heap.
So we leaked about two and a half megs.
So whenever you see your memory go up in kind of a step
function like that, it steps up and just never goes back
down, that's a good sign you have a memory leak.
So once you know that you have a leak, what you'll want to do
is create a heap dump, so you can go about debugging it.
So I'm going to do that right now.
I'll open up DDMS.
You just need to select the process that you care about
and click on this icon up in the toolbar that says dump
HPROF file.
That'll create a heap dump.
It takes a few seconds because it's dumping basically a huge
binary file out to disk.
And then I can just save it in a file called dump.hprof.
And then, because I'm using this standalone version of
DDMS here, I need to convert this file.
As I mentioned, if you're using the ADT plug-in for
Eclipse and using DDMS in there, you don't need to go
through this conversion step.
But it's really simple.
Now that I've converted it, I can open up the Eclipse Memory
Analyzer and take a look at this heap dump.
So there's not much to see in the Memory Analyzer until
you've opened up a heap dump, which we can do just
from the file menu.
Open heap dump.
And I'll open up this converted heap dump, which I
just created.
Doesn't take very long for it to load up.
And the first thing you'll see is this pie chart.
This is showing the biggest objects in the system by
retained size.
Now this alone doesn't really tell us too much.
You can see that down in the bottom left here, when I mouse
over the various slices of the pie, it's telling me what kind
of object I've got.
But that doesn't really tell us too much.
If we want to get some more information, you want
to look down here.
There are two views.
The histogram view and the dominator tree.
And these are the ones that I find most useful and I'm going
to show to you.
Let's take a look at the dominator tree.
You remember the concept I explained.
This is how it can be useful in tracking
down a memory leak.
So what we've got here is basically a list of instances
or a list of objects in this system organized.
There's a column here.
Organized by the amount of retained heap.
So when you've got a memory leak, looking at the amount of
retained heap is often a good way to look at things because
that's going to have the biggest effect on how much
memory you're using.
And chances are, if you've noticed that you've got a
leak, you're leaking a significant amount.
So let me just zoom in here.
Hopefully you guys can see this a bit better.
So at the very top of the list we have the resources class.
That's not too surprising because our resources we have
to load lots of bitmaps.
That's going to hold lots of memory alive.
That's fine.
These two bitmap objects are interesting.
I've got these two large bitmaps, more than two and a
half megs each.
It's funny because that sounds about like the amount of
memory that I was leaking.
So if I want to investigate a bit further, I can right click
on one of these objects and choose path to GC roots.
And I'll chose excluding weak references because I want to
see what's keeping that object alive.
And a weak reference is not going to keep it alive.
So this opened up a new tab and what do you know?
It actually points right to my leak.
So when you're creating leaks in your application, make sure
you name it something really helpful like this so you can
find it easily.
AUDIENCE: [LAUGHTER]
PATRICK DUBROY: So some of you might have noticed this, that
if there's only a single path to this object, because that's
all I can see here, why didn't this leak object show up in
the dominator tree?
I mentioned that the dominator tree should show you the
largest objects by their amount of retained heap.
And well this is a single object that's responsible for
retaining the bitmap.
So the reason for that is that the Eclipse Memory Analyzer,
when it calculates the dominator tree, it actually
doesn't treat weak references separately.
It basically just treats them like a normal reference.
So you'll see that if I actually right click on this
guy again and say path to GC roots, and say with all
references, then there's actually another
path to this object.
But it's a weak reference.
Generally you don't need to be too concerned about weak
references because they're not going to prevent your object
from being garbage collected.
But that's why the leak object didn't show up in the
dominator tree.
So the dominator tree is one really, really useful way of
tracking down a memory leak.
Another thing I like to use is the histogram view.
So I mentioned that in Android, it's common to leak
memory by keeping long lived references to an activity.
So you may want to actually go and look at the number
instances of your main activity class that you have.
And the histogram view lets you do that.
So the histogram view just shows a list of all the
classes in its system and right now it's sorted based on
the amount of shallow heap occupied by
classes in the system.
So at the very top there, we see we have byte arrays.
And the reason for this is that byte arrays are now the
backing memory for pixel data.
And you know, this is a perfect example of why it's
really useful that we now have the pixel
data inside the heap.
Because if you're using this on Gingerbread or earlier,
you're not going to see byte arrays at the top.
Because that memory with allocated in native memory.
So we could also, if we were concerned about these byte
array objects, we might want to right click on it and say
list objects with incoming references.
And we've got our two large byte array objects here.
We can right click on one and say, path to GC roots,
excluding weak references.
So this guy looks to have several paths,
which keep it alive.
Nothing looks out of the ordinary to me.
And when you're trying to find a memory leak, there's not
really a magic answer for how you find a leak.
You really have to understand your system and understand
what objects are alive, why they're alive, during the
various parts of your application.
But you'll see if I look at this other byte array object,
and again, do path to GC roots excluding weak references,
well, I've found my leak again.
So this was another way that I might have found this if it
weren't so obvious from the dominator tree.
The histogram view can also help us look for
our activity instances.
So there's a lot of classes obviously in the system.
Our activity is not here.
There's 2,200 classes.
But luckily, Eclipse Memory Analyzer has this handy little
filter view at the top.
You can just start typing a regular expression.
And it'll return you all the classes that match that.
So here we've got our main activity.
And it tells us that there are actually two instances of this
main activity.
And that should kind of be a red flag.
Normally you should expect to see only a single instance of
your main activity alive.
Now I mentioned during the screen rotation, we build up a
new view hierarchy, there's going to be a brief time where
there's two instances alive.
But for the most part, you should expect to see one here.
So I might think, OK, this is a red flag.
Let's take a look.
So I can right click on this object and list objects with
incoming references.
So I want to look at what instances do I have and what's
pointing to them?
And so I've got two instances here.
If I right click on one of them and choose path to GC
roots, excluding weak references, I've again, found
my memory leak.
And in looking at this, I might realize that, oh, I
really didn't intend to do this.
I didn't mean to keep this reference there.
So that's another way that you could have found the leak.
So now that we've discovered where our memory leak is, why
don't we actually go ahead and fix it.
So in this case, the problem was that we had a non-static
inner class.
So we could fix this by making it a static inner class.
And then it wouldn't actually keep a reference to the
enclosing activity.
The other thing we could do is actually just not store it in
a static variable.
So it's fine if this leaky object has a reference to the
activity, as long as it doesn't live
longer than the activity.
So let's do that.
Let's just make this a regular instance
variable and not a static.
So then I can go in here recompile this and push it to
the device.
And hopefully, we should see that our memory leak has been
eliminated.
Sorry, what we actually want to do is look at our log
output in order to see how much memory we're using.
So I'm just going to fire up the process here, take a look
at the process ID.
And again, just do ADP log cat just on that process.
So as I page through the photos again, we see lots of
GC messages.
When I rotate, we're going to see the memory usage goes up
for a minute there.
But after a few collections, it does go back down to its
previous value.
So we've successfully eliminated the leak there.
And this is great.
You always want to eliminate memory leaks.
So that's an example of using the Eclipse Memory Analyzer to
debug a memory leak.
Eclipse Memory Analyzer is a really powerful tool.
It's a little bit complex.
It actually took me quite a while to figure out that these
were the two best tools for the job.
So you really want to watch out for these memory leaks.
So I gave an example here of retaining a long lived
reference to an activity.
If you've got our context, a view, a drawable, all of these
things you need to watch out for.
Don't hold long lived references to those.
It can also happen with non-static inner classes,
which is what I demonstrated there as well.
Runnable is actually one that can bite you sometimes.
You know, you create a new runnable.
You have a deferred event that's going to run in like
five minutes.
If user rotates the screen that deferred runnable is
going to hold your previous activity instance alive for
five minutes.
So that's not good.
You also want to watch out for caches.
Sometimes you have a cache and you want to keep memory alive,
so that you can load images faster let's say.
But you may inadvertently hold things alive too long.
So that covers basically, the core parts of the Eclipse
Memory Analyzer, and gives you a basic understanding of
memory leaks.
If you'd like to get more information about Memory
Analyzer, the download link you can find on the
eclipse.org/mat site.
Markus Kohler who's one of the original team members of
Eclipse Memory Analyzer, he has a blog called the Java
Performance Blog.
This is really great.
He's got tons of great articles on there about MAT
and different ways you can use it to understand your
applications memory usage.
I've also got an article that I wrote on the Android
Developer Blog called memory analysis for Android
applications.
It covers a lot of the same stuff that I
did in my demo here.
And Romain Guy also has a good article on avoiding memory
leaks in Android.
So I hope that's been helpful, I hope you guys have a better
understanding now of how you can figure out your apps
memory usage.
And I've talked about two of the biggest changes that we've
made in Gingerbread and Honeycomb that affect how your
apps use memory.
Thanks.
[APPLAUSE]
So I can take questions from the floor if anyone has any.
Or you all want to get out and get to a pub and have a beer?
AUDIENCE: Hi, you mentioned that if you use NIO in
Honeycomb your objects are going to be not in native
memory and now they're going to be managed memory.
How does that affect performance if you're doing an
IO, is that going to be any slower, like
very intense on network?
PATRICK DUBROY: No, I mean it shouldn't affect.
So I should say that there is still a way to allocate native
memory for your NIO byte buffers.
I'm not that familiar with the NIO APIs, but I believe
there's a way in JNI you can allocate your own memory.
So in that case, you'll still be using native memory.
But either way, it's just memory.
It's just allocated in a different place.
So there's nothing that makes the Dalvik heap memory slower
than other memory.
AUDIENCE: So you're saying how in Honeycomb the bitmaps are
stored in the Dalvik heap, but in previous versions to that
it was stored on native memory.
Does that mean that bitmaps had a different
amount of heap size?
Or is that still all counted in the 16 or 24 megabytes that
previous versions had?
PATRICK DUBROY: Yeah, good question.
The accounting limits are still the same.
That was accounted for previously.
You might have noticed if you ever ran into your heap limit,
you would be looking at your heap size and like, I haven't
hit the limit yet, why am I'm getting out of memory?
That was actually accounted for, so it was your total heap
size plus the amount of externally allocated memory
that was your limit.
So that hasn't changed.
AUDIENCE: Hello.
I have a question on when does the garbage
collector kicks in.
Is is when a number of objects in memory or
the size of the heap?
PATRICK DUBROY: Well, it depends on what kind of
garbage collection you're talking about.
The concurrent garbage collector--
AUDIENCE: Yeah, the concurrent.
Yes.
PATRICK DUBROY: Yeah, so that I believe is the amount of
basically, how full your heap is getting.
AUDIENCE: Because I noticed that when you do a lot of
[INAUDIBLE]
provide operations, so you have like [INAUDIBLE]
list of operations, the garbage collector kicks in.
But actually don't collect any objects because you're just
filling in the array of objects that you want to
insert into a database.
And that's grow quite quickly.
And that tends to slow down a bit, the application without
actually solving any heap size.
PATRICK DUBROY: Yeah, I'm not sure if the GC looks at--
so you're basically saying, I guess, that the collector is
kicking in.
It's not actually able to collect anything, so it
shouldn't--
AUDIENCE: But it keeps trying.
PATRICK DUBROY: Yeah, it should be smart enough.
Yeah, I don't believe we actually look at those kind of
statistics yet.
But I mean it seems reasonable.
Yeah.
AUDIENCE: I was wondering if you guys have some plans for
making a profiler for applications or more tools for
analyzing memory and all that stuff?
PATRICK DUBROY: No plans that I know of.
Is there anything in particular that you need?
I mean I think the Eclipse Memory Analyzer is a really
powerful tool and I use it in my day-to-day
work quite a bit.
So I've certainly never found that it it was missing certain
features that I needed.
AUDIENCE: Yeah, probably because there are some old
versions from Android that show
memory leaks or something.
But for example, on Eclair, there were
some stuff with the--
something there.
PATRICK DUBROY: Yeah, I mean we don't have any immediate
plans I don't think to running specific tools.
AUDIENCE: OK, thank you.
PATRICK DUBROY: Oh, sorry I've been--
yeah.
AUDIENCE: To my understanding, the native part of a bitmap
memory before was actually an instance of the SKIA library,
of one of the SKIA library bitmap classes.
So is this still there or is it gone now that there is no
more native memory allocated?
PATRICK DUBROY: No, SKIA is still part
of this stack there.
Basically at the point where SKIA calls out to allocate
memory, we actually just call back into the VM and allocate
the memory there rather than calling malloc.
So it's still basically the same mechanism, but the
memory's just coming from a different place.
AUDIENCE: OK.
AUDIENCE: I thought that when I was using my application, I
checked the heap size.
While using the application the heap size was not
significantly going up.
But the amount of memory used by the application, which is
listed in the applications tab under the running applications
is going up significantly.
Sometimes even doubling.
I know that this is a different heap
that is shown there.
It's actually the process heap, right?
Can you tell me what the background of that is that
this is shown there because might like--
I don't have a memory leak and users complain about my
application leaking memory.
Because for the user it looks like it's leaking memory.
PATRICK DUBROY: Right.
Because you're saying there's stuff that's attributed to
your process that are showing up in the--
basically, in system memory?
AUDIENCE: Yeah.
So it's showing the system memory in the applications
tab, which is not really linked to my heap memory.
So that is going up, but I can only control the heap memory.
If I don't have a native application I cannot control
everything else.
PATRICK DUBROY: I mean there are going to be various things
in the system that are going to get larger.
For example, like your JIT code caches.
As the JIT kicks in and is allocating memory, like it
needs to store the compiled code somewhere.
So there's definitely other parts of this system that
allocate memory that's going to kind of get charged to your
application.
But I can't think of why.
I can't think of anything that would be out of the ordinary
really that should cause problems.
AUDIENCE: But do you know if this will be changed maybe in
the future?
That this number is not shown there because for me, it
doesn't make sense to show this number to the end user
because he doesn't understand what it means.
PATRICK DUBROY: I see.
Where is he seeing the number?
AUDIENCE: In the running applications tab.
If he goes to settings, running applications, he can
see the memory usage per application and that's
actually the system memory.
PATRICK DUBROY: I see.
Yeah, I'm not sure what our plans are with that.
Sorry.
I can take a look and I'm not actually sure where it's
getting that number from.
AUDIENCE: OK, thanks.
AUDIENCE: My question's about reasonable expectations of out
of memory errors.
Is it possible to completely eliminate them?
We've been working for a while in getting rid of all the out
of memory errors and down to one in about
every 17,000 sessions.
Should we keep troubleshooting.
I mean, I'd like to get it down to zero, but is that
reasonable or?
PATRICK DUBROY: So there are certain scenarios where if
you're really close to your memory limit, so if your
applications live memory size is really close to that limit,
the garbage collector's fundamentally kind of
asynchronous.
So if you're really close to the limit, there can be times
where you're just trying to allocate so fast that the
garbage collector can't keep up.
So you can be actually sort of out
running the garbage collector.
So certainly it's possible to build applications that never
see an out of memory error.
But on the other hand, there are certain types of
applications that are going to be running really, really
close to the limits.
One thing you can use if you have caches or things that you
can free up, there are several ways to figure out that you're
getting close to the heap memory limit.
I believe there's a callback you can get notification that
we're getting low on memory.
Although, the name escapes me.
But you can also look at that, the Activity Manager, get
memory class to get a sense of how much memory you have
available on the system.
And you know, maybe you can keep like smaller caches or
leave the initialize objects rather than initializing them
all in the constructor or something like that.
It really depends on the application whether you expect
to be running close to that heap limit or not.
AUDIENCE: You recommended not to call system.gc manually if
you can help it.
Is there any way to reliably free bitmap memory
pre-Honeycomb?
PATRICK DUBROY: Yes.
Pre-Honeycomb?
AUDIENCE: Yes.
PATRICK DUBROY: You can call recycle on the bitmap.
AUDIENCE: Yeah, but it can still take several passes
apparently.
PATRICK DUBROY: No.
If you call recycle that will immediately
free the backing memory.
The bitmap itself, that's like 80 bytes or something.
AUDIENCE: There are also bitmaps like drawables that
you can't manually recycle the bitmaps that the drawable
object creates.
PATRICK DUBROY: OK.
AUDIENCE: The backing bitmaps for those.
PATRICK DUBROY: I see.
No, I mean there are still some cases I guess where
system.gc is the right approach.
[UNINTELLIGIBLE PHRASE]
PATRICK DUBROY: OK, which objects are you
talking about in--
AUDIENCE: My experience is when I have image drawables
that are used some where in my layout and I know they're no
longer needed.
Some of them are fairly large and it seems like--
PATRICK DUBROY: You can call recycle on those I believe.
AUDIENCE: OK.
My experience is that it will cause other
problems when I do that.
PATRICK DUBROY: If you're still using
them, then you can't--
I mean, you can only recycle that when you're not using it.
AUDIENCE: Sure.
OK.
AUDIENCE: For native code that uses a lot of mallocs, what's
the best way to manage that memory?
PATRICK DUBROY: That's a very good question.
When you've got native code, I mean mostly what I was
covering here was managing memory from the
Dalvik side of things.
I don't know that I have any real pointers.
I mean that's one of the reasons why programming in a
managed run time is very nice.
Is that you don't have to deal with manually
managing your memory.
I don't have any great advice for that.
AUDIENCE: Does the app that calls into the native
libraries, is it aware of, at least on an aggravate level,
how much memory is being used or is it
completely a separate--
PATRICK DUBROY: I don't believe there's any way to
account for if you're calling into the library and it's
calling malloc.
I don't know that there's any way to account for that memory
from your application side.
AUDIENCE: But that garbage collector will run when you
start allocating memory, will it not?
PATRICK DUBROY: It'll run when you start allocating like
objects in Dalvik.
It doesn't have any knowledge of calls to malloc.
AUDIENCE: You'll just get an out of memory or a failed
malloc if you--
PATRICK DUBROY: Yeah.
Sure.
It's going to be the same mechanisms as
any C or C++ program.
Malloc is going to return a null pointer.
Yes?
AUDIENCE: [UNINTELLIGIBLE PHRASE]
PATRICK DUBROY: Pardon me?
AUDIENCE: [UNINTELLIGIBLE PHRASE]
PATRICK DUBROY: Oh, OK.
That's news to me.
Malloc can't fail on Android.
AUDIENCE: [UNINTELLIGIBLE PHRASE]
PATRICK DUBROY: I see.
OK.
AUDIENCE: Can you repeat that?
PATRICK DUBROY: Romain tells me that malloc
can't fail on Android.
AUDIENCE: [UNINTELLIGIBLE PHRASE]
PATRICK DUBROY: I see.
So I think this is the old Linux lazy--
yeah.
It'll successfully allocate the virtual memory, but Linux
can actually hand out more virtual memory than it can
actually commit.
So you can get problems. Like when your system is totally,
totally out of native memory, you're going to see crashes.
AUDIENCE: So native memory is completely separate from
anything Dalvik?
PATRICK DUBROY: Yes.
Well, I mean, sorry, I should say, like Dalvik is still
allocating its own memory like for the heap through the
native mechanisms. So it's reserving the same virtual
memory pages that other applications are using.
AUDIENCE: But if your system memory is--
PATRICK DUBROY: Yeah, if your system memory is out, you're
in trouble.
AUDIENCE: But Dalvik won't get a notice say, hey, better
start garbage collecting?
PATRICK DUBROY: Well, no.
AUDIENCE: The flag for using larger heap, does that require
a permission, like users permission or
something like that?
PATRICK DUBROY: I can't remember whether we
added that or not.
I don't think that it does.
AUDIENCE: Like the whole--
could it been like a permission thing?
But if it's not then--
PATRICK DUBROY: Yeah, I mean the idea I think is that--
yeah, you're right.
I mean it can affect the system as a whole because
you're going to have apps that are using a lot more memory,
which is why I gave that big warning, that this is not
something that you should be using unless you know that you
really need it.
AUDIENCE: Yeah.
But [INAUDIBLE].
OK.
PATRICK DUBROY: I don't think there's a
permission for it, though.
AUDIENCE: What if the app kind of runs in the background for
weeks at a time?
So I do everything I can to simulate a leak, click
everywhere I can, but I see the leaks if the app runs two
or three days and then I get [INAUDIBLE].
PATRICK DUBROY: One thing you could try is if you can use
the APIs to determine how much free memory you have. I don't
know if there's any way you can actually kind of notice in
your application that it started leaking.
But you could write out an HPROF file when you notice
that you've gotten to a certain point, your heap is
getting smaller and smaller.
So there is some debug information there
that you could use.
So if you have like some beta testers, who could actually
send you these dumps, then you could do that.
So write out the HPROF file to SD card or something.
AUDIENCE: So maybe I can just write an HPROF file every--
PATRICK DUBROY: I wouldn't do that.
I mean they're quite large.
You don't want to be doing that on a regular basis.
But if you detect that things have gone really, really wrong
and you're about to die, in an alpha version or something for
testing that's one way you could do it.
But I definitely wouldn't recommend putting an app in
the market that's dumping like very large files to the SD
card for no reason.
AUDIENCE: OK.
PATRICK DUBROY: OK, thanks a lot.