I'm fairly sure that's not true. If you read the original email thread 
I originally reported a PermGen leak with Guice 1.0. Both 1.0 and trunk 
had some sort of leak (but due to different causes). Stuart's reply 
seems to confirm this: 
http://groups.google.com/group/google-guice/msg/07e1484050f1bc17

Gili

Dhanji R. Prasanna wrote:
> It's not Guice. It's because an instance of something (like a logger)
> from your application is being referenced by something outside your
> application.
> 
> jordi's webapp classloader <- class <- *instance* <- something <-
> something's class <- a parent classloader
> 
> As long as this strong reference chain exists, the JVM will not
> garbage collect jordi's webapp classloader. I doubt Hibernate or c3p0
> is to blame specifically--this can be caused by just about anything
> (most typically, a logging instance from commons-logging.jar in a
> parent CL).
> 
> Dhanji.
> 
> On Tue, Nov 25, 2008 at 10:49 AM, jordi <[EMAIL PROTECTED]> wrote:
>> I'm having similar problems using Guice with Struts 2 + Hibernate.
>>
>> I dunno if Guice is part of the problem, when the PermGen error appears
>> always is related to C3P0 pool created by Hibernate and the Logger stuff.
>>
>> jordi
>>
>> On Tue, Nov 25, 2008 at 7:41 PM, Dhanji R. Prasanna <[EMAIL PROTECTED]>
>> wrote:
>>> Looks like a permgen space problem. The additional 90MB sounds about
>>> right. It's just the old classloader is not being garbage collected
>>> because something is being held on to from a different classloader.
>>>
>>> This problem is difficult to track down.
>>>
>>> Dhanji.
>>>
>>> On Tue, Nov 25, 2008 at 10:17 AM, Pablo Ruggia <[EMAIL PROTECTED]> wrote:
>>>> For Guice and memory leaks, there is an interesting thread here:
>>>> http://www.mail-archive.com/[email protected]/msg00506.html
>>>>
>>>> Also I heard a lot of times that webapps leaking memory on redeploys are
>>>> caused by commons logging, you can take a look here:
>>>> http://wiki.apache.org/jakarta-commons/Logging/FrequentlyAskedQuestions
>>>>
>>>> Cheers !
>>>>
>>>> On Tue, Nov 25, 2008 at 3:59 PM, o_swas <[EMAIL PROTECTED]> wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> I've been reading up on Guice quite a bit and I like what I see.
>>>>> Great work, Google!
>>>>>
>>>>> Like lots of folks we currently use Spring for DI, in addition to
>>>>> transaction management for Hibernate.  We have an application that is
>>>>> fairly large (large for  us, anyways) and has lots of Hibernate
>>>>> objects and Spring-based service beans.
>>>>>
>>>>> The application is deployed to Glassfish v2.  One continuing issue we
>>>>> have with this setup is a memory leak that occurs when ever we
>>>>> redeploy the application.  The application is deployed, but when we
>>>>> redeploy the application (without restarting Glassfish) memory usage
>>>>> increases by 90+ MB.  After a few redeploys, Glassfish runs out of
>>>>> memory and needs to be restarted.  Note that the application *does
>>>>> not* leak memory while it's running; it's only during redeploys that
>>>>> memory leaks.
>>>>>
>>>>> While I'm sure we have some of our in-house written code is to blame,
>>>>> I've long suspected that possibly Hibernate (due to the dynamic
>>>>> proxying that makes all the magic happen) and Spring are culprits in
>>>>> the memory leak.
>>>>>
>>>>> So, after explaining all this, here are my questions:
>>>>>
>>>>> 1.  Can anybody comment on how efficient (or inefficient) Guice is
>>>>> with memory and CPU?  Is Guice likely to have any better runtime
>>>>> performance than Spring, or use less memory during runtime?  Will
>>>>> Guice start up any faster (or slower) than Spring?
>>>>>
>>>>> 2.  Is there anything in Guice that might cause memory leaks in web
>>>>> application when the application is redeployed?  I see Guice uses
>>>>> parts of CGLIB, which I know a few years ago caused some nasty memory
>>>>> leaks in Hibernate (which I've since been fixed, I believe).
>>>>>
>>>>> 3.  In general, can anybody comment on overall runtime performance of
>>>>> Guice compared to Spring?  We don't really have any performance
>>>>> problems now, but I always like to be on the lookout to improve where
>>>>> we can and before we *need* to because the app couldn't scale with
>>>>> usage.
>>>>>
>>>>> Many thanks to Google for offering Guice!!
>>>>>
>>>>> -Ryan
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
> 
> > 
> 

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

Reply via email to