[MTOS-dev] Memory Utilization Brainstorm

[Timothy Appnel]

I've been chomping on this one for a while after realizing that I had
a gross misunderstanding of how Perl's garbage collector works.

As Hirotaka has figured out MT::Template does indeed create a circular
reference that causes those objects to pile up in memory even when on
the surface it looks like they have gone out of scope.

These perl.com articles where enlightening on the topic:

http://www.perl.com/pub/a/2002/08/07/proxyobject.html
http://www.perl.com/pub/a/2007/06/07/better-code-through-destruction.html

The former is a bit old, but explains more of the nuts and bolts of
the problem. The latter gives ways of solving the issue; however, in
experimenting today none of them seem satisfactory to me that I'm
hoping there is a better way. One way is to require the developer to
remember to run a finalize or release method that uncouples the
circular reference. That's a pain as its too easy to forget or lose
track of an object. Another way requires the developer to create an
object destroyer with the same scope as the circular reference
structure. If you stash that object somewhere like MT::Request or
MT::Template::Context as is common then you'll run into objects going
prematurely out of scope. The last is to use an "almost transparent"
wrapper class that Object::Destroyer makes pretty easy. The author of
Object::Destroyer (Adam Kennedy) calls them almost transparent because
if you do a ref on the object that is returned once instantiated you
don't know what class it really is. You get Ob ject::Destroyer
instead. In other words:

   my $tmpl = MT::Template->new; # new wraps the actual MT::Template
with Object::Destoryer
   print ref $tmpl; # prints 'Object::Destroyer' not 'MT::Template'

I suppose one solution is to wrap all MT::Objects with a proxy like
Object::Destroyer and force developers to use a method like class_type
to determine what they are working with but that sounds pretty
unfriendly to me though.

Thoughts?

<tim/>