[MTOS-dev] Circular reference issue

Hirotaka Ogawa hirotaka.ogawa at gmail.com
Mon Jan 21 19:34:45 PST 2008


Let me update 'fix-circular-references' patch.

The former one incurred a problem, that MT failed to handle DOM-based
Transformer plugins because of the lack of declaration to use
Scalar::Util::weaken method.

Also, the updated patch includes a fix for MT::Builder::build() as
described below:

Problem:

MT::Template::build() method stashes a MT::Builder object to $ctx.
Therefore, MT::Builder object stashed is never destroyed until $ctx
died. It doesn't create any circular references, but
$ctx->stash('builder') should only be referred from the inside of
build() method, and the MT::Builder object should properly be
destroyed after builder loop finished.

Modification:
The patch makes $ctx->stash('builder') temporary. After applying this
modification, any methods which use $ctx->stash('builder') may
properly work as far as they are called from MT::Builder::build()
method. This modification may have an impact on compatibility.

Thanks,

On Jan 15, 2008 7:04 PM, Hirotaka Ogawa <hirotaka.ogawa at gmail.com> wrote:
> Hi,
>
> I'm trying to remove circular references in MT/MTOS 4.1.  The attached
> patch is a tentative result of my work.
>
> == Problems ==
>
> 1) MT::Template::context()
>
> MT::Template::context() method may create a circular reference between
> MT::Template::Context and MT::Template.  $tmpl has a reference to
> $ctx, and $ctx has a reference to $tmpl.
>
> 2) MT::Builder::compile() and MT::Builder::_text_block()
>    MT::Template::createElement(), MT::Template::createTextNode(),
> MT::Template::Node::parentNodes()
>
> All these methods may create a circular reference between MT::Builder,
> MT::Template, and MT::Template::Node objects.  It is crucial that 6th
> and 7th parameters of MT::Template::Node sometimes have references to
> other large objects.
>
> == Modifications ==
>
> Basically, the patch includes 2 kinds of modifications to MT::Builder
> and MT::Template classes.
>
> 1) MT::Template::context()
>
> The patch stops storing a MT::Template object to
> $ctx->stash('template') at context() method.  Even after applying this
> modification, MT::Template::build() method stores
> $ctx->stash('template') temporarily. Therefore, any methods which use
> $ctx->stash('template') may properly work as far as they are called
> from MT::Template::build().  This modification may have an impact on
> compatibility.
>
> 2) MT::Builder::compile() and MT::Builder::_text_block()
>    MT::Template::createElement(), MT::Template::createTextNode(),
> MT::Template::Node::parentNodes()
>
> The patch makes their references weak by employing Scalar::Util module
> [http://search.cpan.org/~gbarr/Scalar-List-Utils-1.19/lib/Scalar/Util.pm].
>
> == Test code ==
>
> I have attached two test codes and logs to this message.
>
> t1.pl creates MT::Template object from a short text and builds it
> repeatedly.  And, t2.pl loads Main Index template from the database
> and builds it repeatedly.  After repeated builds, both scripts output
> the amount of remaining objects by using Devel::Leak::Object.
>
> In both tests, the amount of remaining objects are enlarged by the
> repeat count in the original code.  On the other hand, in the modified
> code, the amount are kept constant.
>
> But, as the log shows, t2.pl still has a large amount of
> MT::Template::Node objects remaining in memory.
>
> == Real applications ==
>
> I have tested on a more realistic situation.
>
> Using mod_fcgid and MT::App::Viewer as described at the former post
> [http://www.sixapart.com/pipermail/mtos-dev/2007-December/000211.html],
> I have issued sequential requests (1-1000) by using Apache benchmark,
> and have measured RSS (resident set size) and VSZ (virtual memory
> size) of the FastCGI process.
>
> The results are available from
> [http://spreadsheets.google.com/pub?key=p05llkILPlbIlEVNUgkL0dw].
>
> As results shown, the patch drastically reduces memory usage,
> especially in 1000 times requests, it can cut down almost 80% of
> memory usage.
>
> Unfortunately, I cannot say this patch is an oracle.  Memory usage is
> still enlarged by each requests.
>
> == Caution ==
>
> The patch is not well-tested.
>
> --
> Hirotaka Ogawa makes no sense.
> http://as-is.net/blog/
>



-- 
Hirotaka Ogawa makes no sense.
http://as-is.net/blog/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mtos-r1295-fix-circular-references.patch
Type: text/x-patch
Size: 3163 bytes
Desc: not available
Url : http://www.sixapart.com/pipermail/mtos-dev/attachments/20080122/a12b5257/attachment.bin 


More information about the MTOS-dev mailing list