flex-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: Using Adobe Scout to locate memory leak
Date Thu, 04 Sep 2014 16:39:58 GMT
I don't think there is a loitering objects computation in Scout.  Plus,
even in FlashBuilder, you can't always use Loitering Objects to solve a
memory leak problem.  There are two kinds of memory leak scenarios
described on my blog [2].  Loitering objects only helps with one of them
and there have been many occasions when I've had the "other" scenario.

Fundamentally, loitering objects compares two memory snapshots and reports
which objects were in the second snapshot that weren't in the first one.
Loitering Objects computations are therefore useless when objects are
supposed to get tossed and re-instantiated.  Like if you refresh data
every 10 seconds.  If you had 8 data items, threw them out, and created 8
new ones, Loitering Objects says those 8 are loitering.  Which they are,
but that isn't a leak.

So first, what is your scenario?  Is it one of those, "I leave the
application on overnight and when I come back it has crashed from being
out of memory"?  Or "If users perform this sequence of steps often enough,
the app crashed from being out of memory".

Then try to look at the Scout data.  You may have to write down one
screenful of the allocations and manually compare to what you see a few
minutes later, but if memory is growing, the amount of memory allocated is
also growing and the amount of memory allocated to certain classes or
objects is growing and probably shouldn't and you'll have to keep digging
until you find out what it is.  When I can't use Loitering Objects in
Flash Builder, that's what I have to do: I manually compare two memory
snapshots.  Painful, but works every time.

One other thing: If your app is too big to be profiled by FlashBuilder, it
is a hint that your app could use better modularity. Unless the sequence
of steps to reproduce the memory leak is extraordinarily complex, you
should be able to execute the few steps to get directly to the memory leak
scenario without allocating nearly the amount of objects that you might
otherwise do if you are actually using the application.  Think of a ship
with the sealable doors to stop the ship from sinking when one compartment
springs a leak.  Proper modularity should, in most cases, allow you to
disable parts of the app to help eliminate whole sections from being the
culprit of a memory leak, and thus reduce the allocation count to the
point where FlashBuilder can handle it.  Also, there is a "flaw" in the
garbage collector in Flash in that the mark and sweep algorithm doesn't
really know what pieces of memory are memory pointers and what is data.
I've never seen it happen, but they tell me that the more memory you
allocate, the more likely you will get memory pointers that look like your
data and that can fool the collector into not collecting objects that
should be free.  Also, the collector is supposed to be "opportunistic" in
that it is supposed to stop collecting if too much time has gone by in the
frame, so in theory, it is possible to "out run" the GC by creating
objects faster than it can find and collect.

BTW, the LocalConnection hack supposedly still works and supposedly fully
cleans everything, so you might try that if you haven't.  But again, it
can still be fooled by data looking like pointers.



On 9/4/14 2:40 AM, "DarrenEvans" <darren.evans@allocatesoftware.com> wrote:

>Yes, read that, it was one of the first ones. Gives a reasonable overview
>how memory is allocated but doesn't really get down to the details of
>working with the results Scout gives to locate leaks.
>In our application's architecture we have a common framework and then the
>main application sits on top of this. I had more success getting a very
>basic application (sitting on the framework) compiling in FlashBuilder and
>then using the profiler in that so I could fix any framework leaks first.
>The loitering objects functionality seems a bit more useful (although not
>100% correct) and we have found the biggest part of the leak in the
>framework code using those tools.
>I cannot use the FlashBuilder profiler for our main Application as it's
>big for it to handle. It's REALLY slow and normally crashes after a few
>minutes. So...... back to Adobe Scout to work out where the memory is
>in the application. Is there anything like the loitering objects
>functionality in FlashBuilder profiler?
>Alex Harui wrote
>> Have you read this:
>> http://www.adobe.com/devnet/scout/articles/scout-memory-profiling.html
>View this message in context:
>Sent from the Apache Flex Users mailing list archive at Nabble.com.

View raw message