1. #1
    Sencha User
    Join Date
    May 2011
    Posts
    47
    Vote Rating
    0
    nmb1106 is on a distinguished road

      0  

    Default UI elements not Garbage Collecting

    UI elements not Garbage Collecting


    We use extended GXT elements all over our product that are not getting garbage collected once they are out of use. This is causing a crazy build up of memory that us devs didn't have issues with because we're running juiced machines but a few clients crash almost immediately.

    The biggest and most problematic case is in our panel that we use to display a tree of results of an job the client ran..once they go to view a new result this is executed along with some other stuff in a set results method:

    Code:
        
    public void setResult(final JobProcessorDTO jobDTO, final ResultTreePanelListener rptl)
        {
            if (resultsTreePanel != null)
            {
                remove(resultsTreePanel);
            }
            resultsTreePanel = new ResultsTreePanel(jobDTO, rptl);
            resultsTreePanel.setColumnWidths(savedColWidths);
            }
            if (jobDTO.getMatchResults().size() != 0)
            {
                moreResults.setEnabled(true);
            }
            else
            {
                moreResults.setEnabled(false);
            }
            this.rptl = rptl;
            this.jobDTO = jobDTO;
            add(resultsTreePanel);
            layout();
        }
    When a client runs a single job there can be anything from 1 to 10,000 records and when the select a record to process it returns a list of results and they can itterate through each with a next/previous button..when they itterate to a new result it builds a new results tree panel and rerenders the ResultsPanel. We're expecting the old ResultsTreePanel to get garbage collected but its not..so as you can imagine this causes huge issues as each result viewed jumps the browser memory up around 10,000K and never releases..

    Any help or tips would be greatly appreciated as we're stuck dead in the water with this one

  2. #2
    Sencha User
    Join Date
    May 2011
    Posts
    47
    Vote Rating
    0
    nmb1106 is on a distinguished road

      0  

    Default


    Could you please move this thread to Ext GWT 2.x? Sorry about that..we are on GXT 2.2.5 and GWT 2.4.

  3. #3
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,645
    Vote Rating
    80
    Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice

      0  

    Default


    How do you know it isn't getting GC'd? From the snippet of code provided, it appears you are overwriting the resultsTreePanel variable, which I assume is what you are referring to - assuming there are no other references to that object, it should be safe for the browser to garbage collect. If you do have other references, then it isn't leaking, just 'still referenced', and it would be wrong for it to be garbage collected.

    Again, I don't have a lot of code to go off of, but here's another thought: GXT 2.x's TreePanel and TreeStore are designed to allow the data to be totally replaced in the store, and the panel to update accordingly - is there a reason you are just making a new panel instead?

    For the most part, Java rules about garbage collection applies in GWT as well - just make sure nothing else referenced the object anymore, and the GC will pick it up on the next pass. The only exceptions apply to interacting with JS and the DOM - and in these cases, unless you are writing your own JSNI code, the rule is pretty simple - it also needs to be detached from the dom, i.e. from any other attached widget.

    Chrome's Inspector has heap tools that might help you to track down any references you dont think should still be there. Compile to PRETTY or DETAILED so you can read the results before attempting to see what is getting referenced where.

  4. #4
    Sencha User
    Join Date
    May 2011
    Posts
    47
    Vote Rating
    0
    nmb1106 is on a distinguished road

      0  

    Default


    Thanks for the reply..I'm using VisualVM and taking heap dumps after every iteration and each time it shows there being one additional ResultsTreePanel instance. I'm seeing the same thing when we use extended dialogs..when we close the dialog the memory doesn't reduce and the heap dumps show it still has one instance of that dialog..when we open that dialog again and close it now theirs two and the memory again increases.

    Results tree panel is a bad name, it is really just an extension of ContentPanel and all it really has it in it is a grid, a DTO and an instance of an interface we use to make calls back to the ResultsPanel to update results. The reason we rebuild each time is because the grid to display the results have varying number of columns.

  5. #5
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,645
    Vote Rating
    80
    Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice

      0  

    Default


    From quickly reading your post, it sounds like something else is referenced to that old instance - can VisualVM tell you what is referencing that object still?

    Another thought: As far as I can tell, VisualVM only measures Java processes, so you're profiling Dev Mode, not your real application. Dev Mode may be cheating in a number of ways to properly pretend that it is JavaScript in the browser, so in addition to the general rules of not trusting performance numbers in Dev Mode, I would also not trust memory numbers. Use tools designed to watch the browser's heap, and only run on compiled JavaScript (though it is fine to leave out optimizations like code splitting or obfuscation for the sake of this testing).

  6. #6
    Sencha User
    Join Date
    May 2011
    Posts
    47
    Vote Rating
    0
    nmb1106 is on a distinguished road

      0  

    Default


    I'm trying to use Chrome inspector to see whats going on but I can't see my classes within the heap. Under the Profiles tab, looking at my snapshot 1 heap, I can't seem to find anything that resembles my classes at all. Do I have to do something specific for it to include my classes?

  7. #7
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,645
    Vote Rating
    80
    Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice

      0  

    Default


    As long as you have compiled your code (dev mode won't work) with the style parameter set to PRETTY or DETAILED, you should be able to read the constructor names. Then either start with the types that have lots and lots of instances, or filter for the class names you know might either be big, or have lots of containing data. This is what the top panel is for - starting with constructors that have been invoked, and showing instances that are still on the heap.

    Once you focus on an instance (or a sub-property of an instance, or some other object in the tree, like dom nodes which seem to have a special way of being drawn), the bottom grid shows what references that object, so you can try looking for that object in the first grid, and so on, to find out why it is being retained.

    Take a look at https://developers.google.com/chrome...heap-profiling for more details on how to use this tool. You could also consider filing a support ticket and granting access to the source or a running instance of your app to get some direct help with this.

  8. #8
    Sencha User
    Join Date
    May 2011
    Posts
    47
    Vote Rating
    0
    nmb1106 is on a distinguished road

      0  

    Default


    hmm..Don't see anything useful in there at all. All of the constructor names are showing up as things like X, sz, Ssb, q1c, kS, OS, E2, lz. Bunch of jiberish

  9. #9
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,645
    Vote Rating
    80
    Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice

      0  

    Default


    This means that you have compiled with style=OBF, the default, to produce a small output. This is unreadable.

    Set style to be PRETTY or DETAILED.

  10. #10
    Sencha User
    Join Date
    May 2011
    Posts
    47
    Vote Rating
    0
    nmb1106 is on a distinguished road

      0  

    Default


    Finally got it compiling to detailed by adding it as an option to the JRE on the build. Now we're even more lost as to what the issue is. Both a colleague and I have each ran the product, taken snapshots at several points through out the process of which it crashes. The snapshots on initial log in are the smallest at around 27.5MB for him and 10.5 MB for me. When we take a snapshot after the first step of executing the steps to reproduce the issue our heap sizes jump about 5-7MB. After that the heaps stay consistently at that size even around the time it is about to go down.

    However, if we look at the browser process via task manager you can surely see the memory continually increasing through the process. Chrome starts around 100,000K for my instance and crashes when it nears around 600,000-700,000K.

    This occurs in every browser but the two heap tools that we've tried now both don't reveal that anything is out of place through out the process. The only thing we see is the huge memory the browser takes up.

    Does this tell you anything?

Thread Participants: 1

film izle

hd film izle

film sitesi

takipci kazanma sitesi

takipci kazanma sitesi

güzel olan herşey

takipci alma sitesi

komik eğlenceli videolar