On 6 Aug 2012, at 21:47, Brian Pontarelli wrote: > On Aug 6, 2012, at 1:22 PM, Stuart McCulloch <[email protected]> wrote: > >> On 6 Aug 2012, at 19:56, Brian Pontarelli wrote: >> >>> Bump. Any ideas on why this is happening and how to fix it? It seems like a >>> pretty bad memory leak in Guice that could impact GC on high scale >>> applications. >> >> Just took a quick look and there seem to be two places that may hold onto >> error objects: >> >> The constructor cache in ConstructorInjectorStore >> >> An anonymous class in TypeConverterBindingProcessor >> >> The actual number of objects depends on your application - I just >> instrumented a multi-injector system with hundreds of bindings in total and >> found 33 Errors objects retaining ~4k of heap. >> >> Note that this is not a leak per se, in that it should not increase over the >> time of your application and will eventually get moved into the old space, >> but it is an overhead that could be reduced. >> >> I'll see if I can dig further… > > Our application has 1 injector and hundreds of bindings. We were seeing > hundreds of thousands of these objects in the VM and they consume 10% or more > of the heap (20-30M). I didn't dig too deep, but we were also under massive > load and at points having full GCs.
Yes, it depends on the application how much effect this has (how many child injectors does it use - and how many just-in-time bindings, type converters, etc.) > I think I might have our heap dump laying around if you want it. Sure, if you can share it somewhere I'll take a look (make sure you compress it first, since most heap dumps compress well) > -bp -- You received this message because you are subscribed to the Google Groups "google-guice" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-guice?hl=en.
