com.google.inject.internal.Errors

[Brian Pontarelli]

I'm running some load tests on my application and after the VM ran out of memory I grabbed a heap dump to start investigating. One thing that I noticed was there were around 600,000 instances of the com.google.inject.internal.Errors class and the instances were eating up about 11% of the memory in the VM.

This seems a bit odd and I wanted to ask a few questions. Specifically, why are there so many instances of this class in the VM? Also, why are they so large and consuming so much space if it is expected that Guice will be creating hundreds of thousands or millions of them.

-bp

[glenviewjeff]

This sounds a lot like my post about irrelevant in memory errors on android from a few days ago...

[Brian Pontarelli]

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.

-bp

On Jul 28, 2012, at 2:57 PM, glenviewjeff <glenvi...@gmail.com> wrote:

> This sounds a lot like my post about irrelevant in memory errors on android from a few days ago...
>

> --
> You received this message because you are subscribed to the Google Groups "google-guice" group.
> To view this discussion on the web visit https://groups.google.com/d/msg/google-guice/-/8ocFOLqoFW8J.
> To post to this group, send email to google...@googlegroups.com.
> To unsubscribe from this group, send email to google-guice...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/google-guice?hl=en.
>

[Stuart McCulloch]

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...

[Brian Pontarelli]

On Aug 6, 2012, at 1:22 PM, Stuart McCulloch <mcc...@gmail.com> 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.

I think I might have our heap dump laying around if you want it.

-bp

[Stuart McCulloch]

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