3 Replies Latest reply on Feb 21, 2010 9:58 PM by Flex harUI

    Garbage collection / memory allocation problem.


      There are basically two issues.

      One, garbage collection cycle is not fast enough and when debugging under IE , eventually running out of memory and the IE browser session crashes.


      Two, memory should not be growing that much in the first place.

      Now, let me describe the situation:

      First my environment:

      FB 3, SDK 3.5,  run debug sessions in IE8, with flash debug plug-in  Ver10,0,32,18


      There is a custom component where a Box container which contains an Image control is created once in the createdChildren ()    method.

      Now,  this Box and its Image control are assigned the  x,y  and the source (URL for the image) under event handler that is invoked by  Mouse.ROLL_OVER  event. The handler assigns the x,y  and the source URL, and adds the Box to the displayList of the component.  ( this.addChild(myBox) ); The handler also adds an Event listener and handler for Mouse.ROLL_OUT event.

      The Mouse.ROLL_OUT handler, when invokes first removes itself ( removeListener( ..) ) and also removes the Box from the display list, using removeChild(...).


      ( by-the-way, the event listeners are added with useWeakReference = true , so that in principle they can be GBC as well)


      So far so good, as everything behaves and displays as expected.  When the mouse is over one of the items ( there are many) that listen to the Mouse.ROLL_OVER  event, the box with the proper image is shown, and then disappears when Mouse.ROLL_OUT occurs.


      However,  memory is accumulated much more than I expected as only one Box is created and reused by all consequential execution, via the childAdd   and then removeChild  methods.

      If I wait and not push the application too fast some Garbage collection and memory release occurs, but I can push it and cause the browser session to crash by invoking quick and many Mouse.ROLL_OVER / OUT   events on the target items.


      Basic profiling didn’t  expose anything significant yet, beside the memory accumulation. There are variety of works around I can do if a direct and proper solution is not feasible. But I rather find a “scientific”  explanation first.


      I wonder if anyone encountered a similar situation and can contribute an insight.



        • 1. Re: Garbage collection / memory allocation problem.
          Flex harUI Adobe Employee

          If the profiler says memory is growing, take snapshots at various times,

          remove filters, remove %, sort by class and manually compare the instance

          counts to make sure everything is the same.  If instances of anything are

          growing, figure out why as you have to make sure your instance counts are

          the same before you start looking elsewhere.

          1 person found this helpful
          • 2. Re: Garbage collection / memory allocation problem.
            yoav@cyteam.com Level 1

            To clarify:


            The profiler ( so does the Window’s task manager) shows that memory is allocated ( and growing)  when  the ROLL_OVER / OUT  event handlers are invoked and do their thing.

            Also it shows memory reduction by GBC when that happens.


            Thus, because GBC  does reduce the memory allocation ( either if I wait long enough, or manually via the profiler) I’m assuming that  the operation free-up the memory blocks it consumed by the invocation, and it means that there is no “memory leak”.


            The problems ( as I stated originally) are:

            1.)    Why, GBC is not occurring efficiently to take care of business, and/or how to persuade it to do so.

            2.)    The amount of memory allocated each invocation appears to me much more than I expected, just for addChild / removeChild  of a reusable display box that is only created once.


            I’ll take your advice and do a more thorough  profiling to get to the bottom of this.

            Hoping for a shortcut is allowed (only occasionally...)


            • 3. Re: Garbage collection / memory allocation problem.
              Flex harUI Adobe Employee

              There is a hack using LocalConnection to try to force GC.  GC is only

              otherwise called during allocations as pages of memory fill up.  If you are

              running a cycle (create stuff, free stuff, create stuff of the same size)

              memory really should not grow unless you are creating "lots of stuff".  GC

              will not clean everything if it runs out of time.  If you force GC, you may

              see hitches.


              I don't really think there is a shortcut here.  Compare some snapshots.  If

              something isn't being freed (like a bitmap) you will see growth.