You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Jason Pyeron <jp...@pdinc.us> on 2007/02/16 17:36:58 UTC
RE: PermGen space [ot]
So how should one write their singleton?
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- -
- Jason Pyeron PD Inc. http://www.pdinc.us -
- Sr. Consultant 10 West 24th Street #100 -
- +1 (443) 269-1555 x333 Baltimore, Maryland 21218 -
- -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is for the designated recipient only and may contain
privileged, proprietary, or otherwise private information. If you
have received it in error, purge the message from your system and
notify the sender immediately. Any other use of the email by you
is prohibited.
-----Original Message-----
From: Leon Rosenberg [mailto:rosenberg.leon@googlemail.com]
Sent: Friday, February 16, 2007 11:33
To: Tomcat Users List
Subject: Re: PermGen space
something like this:
public class ASingletonImpl{
private static ASingletonImpl instance;
public synchronized AsingletonImpl getInstance(){
if (instance==null){
instance = new ASingletonImpl();
}
return instance;
}
///real code here
}
The problem is the cyclic dependence between the Class object, the
ASingletonImpl object and the according ClassLoader. This way nothing
can be freed by the gc.
regards
Leon
On 2/16/07, Jiang, Peiyun <Pe...@nrc-cnrc.gc.ca> wrote:
> Just curious, can you elaborate on badly programmed singletons?
>
> Thanks.
>
> Peiyun
>
> -----Original Message-----
> From: Leon Rosenberg [mailto:rosenberg.leon@googlemail.com]
> Sent: February 16, 2007 11:08 AM
> To: Tomcat Users List
> Subject: Re: PermGen space
>
>
> The typical problem here are badly programmed singletons. Do you have any?
>
> regards
> Leon
>
> On 2/16/07, Davide Romanini <d....@cineca.it> wrote:
> > I'm too have this problem, it arises because for some reason the Tomcat
> > WebAppClassloader cannot be garbage collected after undeploy. I made a
> > lot of tests and didn't find any solution, also very simple and small
> > webapps, when loaded/unloaded frequently, caused the problem... :-(
> >
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: PermGen space [ot]
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Leon Rosenberg [mailto:rosenberg.leon@googlemail.com]
> Subject: Re: PermGen space [ot]
>
> but if the factory is a pure static utility, calling
> ASingleton myCopy = ASingletonFactory.getASingleton();
> will leave no references to the factory class :-)
Unless the factory is being called by reflection, there certainly will
be a reference to it - from the caller (the class reference in your line
of code above). If the caller is under the same classloader as the
factory, then it won't matter - but in that case it wouldn't matter if
there were no factory involved and it was just a direct reference to the
singleton. All the factory does is provide another layer of
indirection, nothing else.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: PermGen space [ot]
Posted by Leon Rosenberg <ro...@googlemail.com>.
On 2/16/07, Caldarale, Charles R <Ch...@unisys.com> wrote:
> > From: Leon Rosenberg [mailto:rosenberg.leon@googlemail.com]
> > As soon as the factory class is released nothing references
> > the singleton impl object and it can be released.
>
> Agreed - the trick is avoiding the direct reference to the factory
> class.
but if the factory is a pure static utility, calling
ASingleton myCopy = ASingletonFactory.getASingleton();
will leave no references to the factory class :-)
regards
Leon
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: PermGen space [ot]
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Leon Rosenberg [mailto:rosenberg.leon@googlemail.com]
> Subject: Re: PermGen space [ot]
>
> But as long as the factory itself isn't linked by an attribute which
> is inside the impl, the factory class can be released.
Not if there's a direct reference to the factory class somewhere, rather
than a reference by reflection. Any class entries in the constant pool
of another live class are considered active by GC, and therefore cannot
be discarded. Accessing the factory by reflection avoids this, since
the reference is symbolic, not direct. Likewise, referencing the
original singleton class in your example via reflection would also allow
it to be collected once the caller nulled out its own reference to the
returned singleton.
> As soon as the factory class is released nothing references
> the singleton impl object and it can be released.
Agreed - the trick is avoiding the direct reference to the factory
class.
> Now without the factory, we have a situation where the
> classloader can't be released since its referenced by the class
> object, which is referenced by the impl object, which is again
> referenced by the class object (as the static variable).
The above is not a problem - the only thing keeping that set from being
GC'd is some direct reference from outside the set. Again, using
reflection instead of the direct reference would allow the set to be
collected.
> With suns jdk 1.5 i actually experienced oome on redeploy with code
> without any issues mentioned by your article. After we removed
> singleton dependency it went away.
And what else changed?
Note that the Sun JVM has a history of subtle bugs which prevent proper
GC operation in odd cases. One such example is this:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5033614
In this instance the server compiler created an exception object that
hung around essentially indefinitely, and it contained a stack trace
that happened to hold a reference to an otherwise dead object. That one
reference prevented GC of the object, class, and classloader.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: PermGen space [ot]
Posted by Leon Rosenberg <ro...@googlemail.com>.
Chuck,
I know that your knowledge of jvm internals is far superior to mine
and maybe I'm just missing a point, but for me the difference is
obvious.
The Factory only has a static field. That means that Impl class and
impl object can't be released as long as the factory isn't released.
But as long as the factory itself isn't linked by an attribute which
is inside the impl, the factory class can be released. As soon as the
factory class is released nothing references the singleton impl object
and it can be released. If its released so is it class, and its
classloader which is or helds the webapp classloader.
Now without the factory, we have a situation where the
classloader can't be released since its referenced by the class
object, which is referenced by the impl object, which is again
referenced by the class object (as the static variable).
With suns jdk 1.5 i actually experienced oome on redeploy with code
without any issues mentioned by your article. After we removed
singleton dependency it went away.
regards
Leon
On 2/16/07, Caldarale, Charles R <Ch...@unisys.com> wrote:
> > From: Leon Rosenberg [mailto:rosenberg.leon@googlemail.com]
> > Subject: Re: PermGen space [ot]
> >
> > public class ASingletonFactory{
> > private static ASingletonImpl instance = new ASingletonImpl();
> > public static AsingletonImpl getInstance(){
> > return instance;
> > }
> > }
> >
> > public class ASingletonImpl{
> > ASingletonImpl(){
> > }
> > ///real code here
> > }
>
> That does not alter the situation in the least, if any other class
> contains a reference to the factory, since the factory contains a
> reference to the singleton class. If the factory is accessed via
> reflection rather than direct reference, then both the factory and
> singleton can be collected when not in use. The same could be said for
> the previous version of the example.
>
> - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
> MATERIAL and is thus for use only by the intended recipient. If you
> received this in error, please contact the sender and delete the e-mail
> and its attachments from all computers.
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: PermGen space [ot]
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Leon Rosenberg [mailto:rosenberg.leon@googlemail.com]
> Subject: Re: PermGen space [ot]
>
> public class ASingletonFactory{
> private static ASingletonImpl instance = new ASingletonImpl();
> public static AsingletonImpl getInstance(){
> return instance;
> }
> }
>
> public class ASingletonImpl{
> ASingletonImpl(){
> }
> ///real code here
> }
That does not alter the situation in the least, if any other class
contains a reference to the factory, since the factory contains a
reference to the singleton class. If the factory is accessed via
reflection rather than direct reference, then both the factory and
singleton can be collected when not in use. The same could be said for
the previous version of the example.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: PermGen space [ot]
Posted by Leon Rosenberg <ro...@googlemail.com>.
separate the singleton itself and the factory.
in the previous example:
public class ASingletonFactory{
private static ASingletonImpl instance = new ASingletonImpl();
public static AsingletonImpl getInstance(){
return instance;
}
}
public class ASingletonImpl{
ASingletonImpl(){
}
///real code here
}
regards
Leon
On 2/16/07, Jason Pyeron <jp...@pdinc.us> wrote:
> So how should one write their singleton?
>
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> - -
> - Jason Pyeron PD Inc. http://www.pdinc.us -
> - Sr. Consultant 10 West 24th Street #100 -
> - +1 (443) 269-1555 x333 Baltimore, Maryland 21218 -
> - -
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>
> This message is for the designated recipient only and may contain
> privileged, proprietary, or otherwise private information. If you
> have received it in error, purge the message from your system and
> notify the sender immediately. Any other use of the email by you
> is prohibited.
>
>
> -----Original Message-----
> From: Leon Rosenberg [mailto:rosenberg.leon@googlemail.com]
> Sent: Friday, February 16, 2007 11:33
> To: Tomcat Users List
> Subject: Re: PermGen space
>
> something like this:
>
> public class ASingletonImpl{
> private static ASingletonImpl instance;
> public synchronized AsingletonImpl getInstance(){
> if (instance==null){
> instance = new ASingletonImpl();
> }
> return instance;
> }
>
> ///real code here
> }
>
> The problem is the cyclic dependence between the Class object, the
> ASingletonImpl object and the according ClassLoader. This way nothing
> can be freed by the gc.
>
> regards
> Leon
>
>
> On 2/16/07, Jiang, Peiyun <Pe...@nrc-cnrc.gc.ca> wrote:
> > Just curious, can you elaborate on badly programmed singletons?
> >
> > Thanks.
> >
> > Peiyun
> >
> > -----Original Message-----
> > From: Leon Rosenberg [mailto:rosenberg.leon@googlemail.com]
> > Sent: February 16, 2007 11:08 AM
> > To: Tomcat Users List
> > Subject: Re: PermGen space
> >
> >
> > The typical problem here are badly programmed singletons. Do you have any?
> >
> > regards
> > Leon
> >
> > On 2/16/07, Davide Romanini <d....@cineca.it> wrote:
> > > I'm too have this problem, it arises because for some reason the Tomcat
> > > WebAppClassloader cannot be garbage collected after undeploy. I made a
> > > lot of tests and didn't find any solution, also very simple and small
> > > webapps, when loaded/unloaded frequently, caused the problem... :-(
> > >
> >
> > ---------------------------------------------------------------------
> > To start a new topic, e-mail: users@tomcat.apache.org
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To start a new topic, e-mail: users@tomcat.apache.org
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org