/usr/share/doc/libapache2-mod-perl2-doc/docs/2.0/user/design/design.html is in libapache2-mod-perl2-doc 2.0.8+httpd24-r1449661-6ubuntu2.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 | <?xml version="1.0" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title></title>
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
<link rev="made" href="mailto:root@localhost" />
</head>
<body style="background-color: white">
<ul id="index">
<li><a href="#NAME">NAME</a></li>
<li><a href="#Description">Description</a></li>
<li><a href="#Introduction">Introduction</a></li>
<li><a href="#Interpreter-Management">Interpreter Management</a>
<ul>
<li><a href="#TIPool">TIPool</a></li>
<li><a href="#Virtual-Hosts">Virtual Hosts</a></li>
<li><a href="#Further-Enhancements">Further Enhancements</a></li>
</ul>
</li>
<li><a href="#Hook-Code-and-Callbacks">Hook Code and Callbacks</a></li>
<li><a href="#Perl-interface-to-the-Apache-API-and-Data-Structures">Perl interface to the Apache API and Data Structures</a>
<ul>
<li><a href="#Advantages-to-generating-XS-code">Advantages to generating XS code</a></li>
<li><a href="#Lvalue-methods">Lvalue methods</a></li>
</ul>
</li>
<li><a href="#Filter-Hooks">Filter Hooks</a></li>
<li><a href="#Directive-Handlers">Directive Handlers</a></li>
<li><a href="#Perl-Configuration-Sections"><Perl> Configuration Sections</a></li>
<li><a href="#Protocol-Module-Support">Protocol Module Support</a></li>
<li><a href="#mod_perl-MPM">mod_perl MPM</a></li>
<li><a href="#Build-System">Build System</a></li>
<li><a href="#Test-Framework">Test Framework</a></li>
<li><a href="#CGI-Emulation">CGI Emulation</a></li>
<li><a href="#Apache2::-Library">Apache2::* Library</a></li>
<li><a href="#Perl-Enhancements">Perl Enhancements</a>
<ul>
<li><a href="#GvSHARED">GvSHARED</a></li>
<li><a href="#Shared-SvPVX">Shared SvPVX</a></li>
<li><a href="#Compile-time-method-lookups">Compile-time method lookups</a></li>
<li><a href="#Memory-management-hooks">Memory management hooks</a></li>
<li><a href="#Opcode-hooks">Opcode hooks</a></li>
</ul>
</li>
<li><a href="#Maintainers">Maintainers</a></li>
<li><a href="#Authors">Authors</a></li>
</ul>
<h1 id="NAME">NAME</h1>
<p>Notes on the design and goals of mod_perl-2.0</p>
<h1 id="Description">Description</h1>
<p>Notes on the design and goals of mod_perl-2.0.</p>
<p>We try to keep this doc in sync with the development, so some items discussed here were already implemented, while others are only planned. If you find some inconsistencies in this document please let the list know.</p>
<h1 id="Introduction">Introduction</h1>
<p>In version 2.0 of mod_perl, the basic concept of 1.0 still applies:</p>
<pre><code> Provide complete access to the Apache C API
via the Perl programming language.</code></pre>
<p>Rather than "porting" mod_perl-1.0 to Apache 2.0, mod_perl-2.0 is being implemented as a complete re-write from scratch.</p>
<p>For a more detailed introduction and functionality overview, see <a>Overview</a>.</p>
<h1 id="Interpreter-Management">Interpreter Management</h1>
<p>In order to support mod_perl in a multi-threaded environment, mod_perl-2.0 will take advantage of Perl's <i>ithreads</i> feature, new to Perl version 5.6.0. This feature encapsulates the Perl runtime inside a thread-safe <i>PerlInterpreter</i> structure. Each thread which needs to serve a mod_perl request will need its own <i>PerlInterpreter</i> instance.</p>
<p>Rather than create a one-to-one mapping of <i>PerlInterpreter</i> per-thread, a configurable pool of interpreters is managed by mod_perl. This approach will cut down on memory usage simply by maintaining a minimal number of intepreters. It will also allow re-use of allocations made within each interpreter by recycling those which have already been used. This was not possible in the 1.3.x model, where each child has its own interpreter and no control over which child Apache dispatches the request to.</p>
<p>The interpreter pool is only enabled if Perl is built with -Dusethreads otherwise, mod_perl will behave just as 1.0, using a single interpreter, which is only useful when Apache is configured with the prefork mpm.</p>
<p>When the server is started, a Perl interpreter is constructed, compiling any code specified in the configuration, just as 1.0 does. This interpreter is referred to as the "parent" interpreter. Then, for the number of <i>PerlInterpStart</i> configured, a (thread-safe) clone of the parent interpreter is made (via perl_clone()) and added to the pool of interpreters. This clone copies any writeable data (e.g. the symbol table) and shares the compiled syntax tree. From my measurements of a <i>startup.pl</i> including a few random modules:</p>
<pre><code> use CGI ();
use POSIX ();
use IO ();
use SelfLoader ();
use AutoLoader ();
use B::Deparse ();
use B::Terse ();
use B ();
use B::C ();</code></pre>
<p>The parent adds 6M size to the process, each clone adds less than half that size, ~2.3M, thanks to the shared syntax tree.</p>
<p>NOTE: These measurements were made prior to finding memory leaks related to perl_clone() in 5.6.0 and the GvSHARED optimization.</p>
<p>At request time, If any Perl*Handlers are configured, an available interpreter is selected from the pool. As there is a <i>conn_rec</i> and <i>request_rec</i> per thread, a pointer is saved in either the conn_rec->pool or request_rec->pool, which will be used for the lifetime of that request. For handlers that are called when threads are not running (<code>PerlChild{Init,Exit}Handler</code>), the parent interpreter is used. Several configuration directives control the interpreter pool management:</p>
<dl>
<dt id="PerlInterpStart">PerlInterpStart</dt>
<dd>
<p>The number of intepreters to clone at startup time.</p>
</dd>
<dt id="PerlInterpMax">PerlInterpMax</dt>
<dd>
<p>If all running interpreters are in use, mod_perl will clone new interpreters to handle the request, up until this number of interpreters is reached. when <code>PerlInterpMax</code> is reached, mod_perl will block (via COND_WAIT()) until one becomes available (signaled via COND_SIGNAL())</p>
</dd>
<dt id="PerlInterpMinSpare">PerlInterpMinSpare</dt>
<dd>
<p>The minimum number of available interpreters this parameter will clone interpreters up to <code>PerlInterpMax</code>, before a request comes in.</p>
</dd>
<dt id="PerlInterpMaxSpare">PerlInterpMaxSpare</dt>
<dd>
<p>mod_perl will throttle down the number of interpreters to this number as those in use become available</p>
</dd>
<dt id="PerlInterpMaxRequests">PerlInterpMaxRequests</dt>
<dd>
<p>The maximum number of requests an interpreter should serve, the interpreter is destroyed when the number is reached and replaced with a fresh one.</p>
</dd>
<dt id="PerlInterpScope">PerlInterpScope</dt>
<dd>
<p>As mentioned, when a request in a threaded mpm is handled by mod_perl, an interpreter must be pulled from the interpreter pool. The interpreter is then only available to the thread that selected it, until it is released back into the interpreter pool. By default, an interpreter will be held for the lifetime of the request, equivalent to this configuration:</p>
<pre><code> PerlInterpScope request</code></pre>
<p>For example, if a <code>PerlAccessHandler</code> is configured, an interpreter will be selected before it is run and not released until after the logging phase.</p>
<p>Intepreters will be shared across subrequests by default, however, it is possible to configure the intepreter scope to be per-subrequest on a per-directory basis:</p>
<pre><code> PerlInterpScope subrequest</code></pre>
<p>With this configuration, an autoindex generated page for example would select an interpreter for each item in the listing that is configured with a Perl*Handler.</p>
<p>It is also possible to configure the scope to be per-handler:</p>
<pre><code> PerlInterpScope handler</code></pre>
<p>With this configuration, an interpreter will be selected before <code>PerlAccessHandlers</code> are run, and putback immediately afterwards, before Apache moves onto the authentication phase. If a <code>PerlFixupHandler</code> is configured further down the chain, another interpreter will be selected and again putback afterwards, before <code>PerlResponseHandler</code> is run.</p>
<p>For protocol handlers, the interpreter is held for the lifetime of the connection. However, a C protocol module might hook into mod_perl (e.g. mod_ftp) and provide a <code>request_rec</code> record. In this case, the default scope is that of the request. Should a mod_perl handler want to maintain state for the lifetime of an ftp connection, it is possible to do so on a per-virtualhost basis:</p>
<pre><code> PerlInterpScope connection</code></pre>
</dd>
</dl>
<h2 id="TIPool">TIPool</h2>
<p>The interpreter pool is implemented in terms of a "TIPool" (Thread Item Pool), a generic api which can be reused for other data such as database connections. A Perl interface will be provided for the <i>TIPool</i> mechanism, which, for example, will make it possible to share a pool of DBI connections.</p>
<h2 id="Virtual-Hosts">Virtual Hosts</h2>
<p>The interpreter management has been implemented in a way such that each <code><VirtualHost></code> can have its own parent Perl interpreter and/or MIP (Mod_perl Interpreter Pool). It is also possible to disable mod_perl for a given virtual host.</p>
<h2 id="Further-Enhancements">Further Enhancements</h2>
<ul>
<li><p>The interpreter pool management could be moved into its own thread.</p>
</li>
<li><p>A "garbage collector", which could also run in its own thread, examining the padlists of idle interpreters and deciding to release and/or report large strings, array/hash sizes, etc., that Perl is keeping around as an optimization.</p>
</li>
</ul>
<h1 id="Hook-Code-and-Callbacks">Hook Code and Callbacks</h1>
<p>The code for hooking mod_perl in the various phases, including <code>Perl*Handler</code> directives is generated by the <code>ModPerl::Code</code> module. Access to all hooks will be provided by mod_perl in both the traditional <code>Perl*Handler</code> configuration fashion and via dynamic registration methods (the ap_hook_* functions).</p>
<p>When a mod_perl hook is called for a given phase, the glue code has an index into the array of handlers, so it knows to return DECLINED right away if no handlers are configured, without entering the Perl runtime as 1.0 did. The handlers are also now stored in an apr_array_header_t, which is much lighter and faster than using a Perl AV, as 1.0 did. And more importantly, keeps us out of the Perl runtime until we're sure we need to be there.</p>
<p><code>Perl*Handler</code>s are now "compiled", that is, the various forms of:</p>
<pre><code> PerlResponseHandler MyModule->handler
# defaults to MyModule::handler or MyModule->handler
PerlResponseHandler MyModule
PerlResponseHandler $MyObject->handler
PerlResponseHandler 'sub { print "foo\n"; return OK }'</code></pre>
<p>are only parsed once, unlike 1.0 which parsed every time the handler was used. There will also be an option to parse the handlers at startup time. Note: this feature is currently not enabled with threads, as each clone needs its own copy of Perl structures.</p>
<p>A "method handler" is now specified using the `method' sub attribute, e.g.</p>
<pre><code> sub handler : method {};</code></pre>
<p>instead of 1.0's</p>
<pre><code> sub handler ($$) {}</code></pre>
<h1 id="Perl-interface-to-the-Apache-API-and-Data-Structures">Perl interface to the Apache API and Data Structures</h1>
<p>In 1.0, the Perl interface back into the Apache API and data structures was done piecemeal. As functions and structure members were found to be useful or new features were added to the Apache API, the xs code was written for them here and there.</p>
<p>The goal for 2.0 is to generate the majority of xs code and provide thin wrappers where needed to make the API more Perlish. As part of this goal, nearly the entire APR and Apache API, along with their public data structures is covered from the get-go. Certain functions and structures which are considered "private" to Apache or otherwise un-useful to Perl don't get glued.</p>
<p>The Apache header tree is parsed into Perl data structures which live in the generated <code>Apache2::FunctionTable</code> and <code>Apache2::StructureTable</code> modules. For example, the following function prototype:</p>
<pre><code> AP_DECLARE(int) ap_meets_conditions(request_rec *r);</code></pre>
<p>is parsed into the following Perl structure:</p>
<pre><code> {
'name' => 'ap_meets_conditions'
'return_type' => 'int',
'args' => [
{
'name' => 'r',
'type' => 'request_rec *'
}
],
},</code></pre>
<p>and the following structure:</p>
<pre><code> typedef struct {
uid_t uid;
gid_t gid;
} ap_unix_identity_t;</code></pre>
<p>is parsed into:</p>
<pre><code> {
'type' => 'ap_unix_identity_t'
'elts' => [
{
'name' => 'uid',
'type' => 'uid_t'
},
{
'name' => 'gid',
'type' => 'gid_t'
}
],
}</code></pre>
<p>Similar is done for the mod_perl source tree, building <code>ModPerl::FunctionTable</code> and <code>ModPerl::StructureTable</code>.</p>
<p>Three files are used to drive these Perl structures into the generated xs code:</p>
<dl>
<dt id="lib-ModPerl-function.map">lib/ModPerl/function.map</dt>
<dd>
<p>Specifies which functions are made available to Perl, along with which modules and classes they reside in. Many functions will map directly to Perl, for example the following C code:</p>
<pre><code> static int handler (request_rec *r) {
int rc = ap_meets_conditions(r);
...</code></pre>
<p>maps to Perl like so:</p>
<pre><code> sub handler {
my $r = shift;
my $rc = $r->meets_conditions;
...</code></pre>
<p>The function map is also used to dispatch Apache/APR functions to thin wrappers, rewrite arguments and rename functions which make the API more Perlish where applicable. For example, C code such as:</p>
<pre><code> char uuid_buf[APR_UUID_FORMATTED_LENGTH+1];
apr_uuid_t uuid;
apr_uuid_get(&uuid)
apr_uuid_format(uuid_buf, &uuid);
printf("uuid=%s\n", uuid_buf);
</code></pre>
<p>is remapped to a more Perlish convention:</p>
<pre><code> printf "uuid=%s\n", APR::UUID->new->format;</code></pre>
</dd>
<dt id="lib-ModPerl-structure.map">lib/ModPerl/structure.map</dt>
<dd>
<p>Specifies which structures and members of each are made available to Perl, along with which modules and classes they reside in.</p>
</dd>
<dt id="lib-ModPerl-type.map">lib/ModPerl/type.map</dt>
<dd>
<p>This file defines how Apache/APR types are mapped to Perl types and vice-versa. For example:</p>
<pre><code> apr_int32_t => SvIV
apr_int64_t => SvNV
server_rec => SvRV (Perl object blessed into the Apache2::ServerRec class) </code></pre>
</dd>
</dl>
<h2 id="Advantages-to-generating-XS-code">Advantages to generating XS code</h2>
<ul>
<li><p>Not tied tightly to xsubpp</p>
</li>
<li><p>Easy adjustment to Apache 2.0 API/structure changes</p>
</li>
<li><p>Easy adjustment to Perl changes (e.g., Perl 6)</p>
</li>
<li><p>Ability to "discover" hookable third-party C modules.</p>
</li>
<li><p>Cleanly take advantage of features in newer Perls</p>
</li>
<li><p>Optimizations can happen across-the-board with one-shot</p>
</li>
<li><p>Possible to AUTOLOAD XSUBs</p>
</li>
<li><p>Documentation can be generated from code</p>
</li>
<li><p>Code can be generated from documentation</p>
</li>
</ul>
<h2 id="Lvalue-methods">Lvalue methods</h2>
<p>A new feature to Perl 5.6.0 is <i>lvalue subroutines</i>, where the return value of a subroutine can be directly modified. For example, rather than the following code to modify the uri:</p>
<pre><code> $r->uri($new_uri);</code></pre>
<p>the same result can be accomplished with the following syntax:</p>
<pre><code> $r->uri = $new_uri;</code></pre>
<p>mod_perl-2.0 will support <i>lvalue subroutines</i> for all methods which access Apache and APR data structures.</p>
<h1 id="Filter-Hooks">Filter Hooks</h1>
<p>mod_perl 2.0 provides two interfaces to filtering, a direct mapping to buckets and bucket brigades and a simpler, stream-oriented interface. This is discussed in the <a>Chapter on filters</a>.</p>
<h1 id="Directive-Handlers">Directive Handlers</h1>
<p>mod_perl 1.0 provides a mechanism for Perl modules to implement first-class directive handlers, but requires an XS file to be generated and compiled. The 2.0 version provides the same functionality, but does not require the generated XS module (i.e. everything is implemented in pure Perl).</p>
<h1 id="Perl-Configuration-Sections"><Perl> Configuration Sections</h1>
<p>The ability to write configuration in Perl carries over from 1.0, but but implemented much different internally. The mapping of a Perl symbol table fits cleanly into the new <i>ap_directive_t</i> API, unlike the hoop jumping required in mod_perl 1.0.</p>
<h1 id="Protocol-Module-Support">Protocol Module Support</h1>
<p><a>Protocol module</a> support is provided out-of-the-box, as the hooks and API are covered by the generated code blankets. Any functionality for assisting protocol modules should be folded back into Apache if possible.</p>
<h1 id="mod_perl-MPM">mod_perl MPM</h1>
<p>It will be possible to write an MPM (Multi-Processing Module) in Perl. mod_perl will provide a mod_perl_mpm.c framework which fits into the server/mpm standard convention. The rest of the functionality needed to write an MPM in Perl will be covered by the generated xs code blanket.</p>
<h1 id="Build-System">Build System</h1>
<p>The biggest mess in 1.0 is mod_perl's Makefile.PL, the majority of logic has been broken down and moved to the <code>Apache2::Build</code> module. The <i>Makefile.PL</i> will construct an <code>Apache2::Build</code> object which will have all the info it needs to generate scripts and <i>Makefile</i>s that apache-2.0 needs. Regardless of what that scheme may be or change to, it will be easy to adapt to with build logic/variables/etc., divorced from the actual <i>Makefile</i>s and configure scripts. In fact, the new build will stay as far away from the Apache build system as possible. The module library (<i>libmodperl.so</i> or <i>libmodperl.a</i>) is built with as little help from Apache as possible, using only the <code>INCLUDEDIR</code> provided by <i>apxs</i>.</p>
<p>The new build system will also "discover" XS modules, rather than hard-coding the XS module names. This allows for switchabilty between static and dynamic builds, no matter where the xs modules live in the source tree. This also allows for third-party xs modules to be unpacked inside the mod_perl tree and built static without modification to the mod_perl Makefiles.</p>
<p>For platforms such as Win32, the build files are generated similar to how unix-flavor <i>Makefile</i>s are.</p>
<h1 id="Test-Framework">Test Framework</h1>
<p>Similar to 1.0, mod_perl-2.0 provides a 'make test' target to exercise as many areas of the API and module features as possible.</p>
<p>The test framework in 1.0, like several other areas of mod_perl, was cobbled together over the years. mod_perl 2.0 provides a test framework that is usable not only for mod_perl, but for third-party <code>Apache2::*</code> modules and Apache itself. See <code><a>Apache::Test</a></code>.</p>
<h1 id="CGI-Emulation">CGI Emulation</h1>
<p>As a side-effect of embedding Perl inside Apache and caching compiled code, mod_perl has been popular as a CGI accelerator. In order to provide a CGI-like environment, mod_perl must manage areas of the runtime which have a longer lifetime than when running under mod_cgi. For example, the <code>%ENV</code> environment variable table, <code>END</code> blocks, <code>@INC</code> include paths, etc.</p>
<p>CGI emulation is supported in mod_perl 2.0, but done so in a way that it is encapsulated in its own handler. Rather than 1.0 which uses the same response handler, regardless if the module requires CGI emulation or not. With an <i>ithreads</i> enabled Perl, it's also possible to provide more robust namespace protection.</p>
<p>Notice that <code>ModPerl::Registry</code> is used instead of 1.0's <code>Apache::Registry</code>, and similar for other registry groups. <code>ModPerl::RegistryCooker</code> makes it easy to write your own customizable registry handler.</p>
<h1 id="Apache2::-Library">Apache2::* Library</h1>
<p>The majority of the standard <code>Apache2::*</code> modules in 1.0 are supported in 2.0. The main goal being that the non-core CGI emulation components of these modules are broken into small, re-usable pieces to subclass Apache::Registry like behavior.</p>
<h1 id="Perl-Enhancements">Perl Enhancements</h1>
<p>Most of the following items were projected for inclusion in perl 5.8.0, but that didn't happen. While these enhancements do not preclude the design of mod_perl-2.0, they could make an impact if they were implemented/accepted into the Perl development track.</p>
<h2 id="GvSHARED">GvSHARED</h2>
<p>(Note: This item wasn't implemented in Perl 5.8.0)</p>
<p>As mentioned, the perl_clone() API will create a thread-safe interpreter clone, which is a copy of all mutable data and a shared syntax tree. The copying includes subroutines, each of which take up around 255 bytes, including the symbol table entry. Multiply that number times, say 1200, is around 300K, times 10 interpreter clones, we have 3Mb, times 20 clones, 6Mb, and so on. Pure perl subroutines must be copied, as the structure includes the <code>PADLIST</code> of lexical variables used within that subroutine. However, for XSUBs, there is no PADLIST, which means that in the general case, perl_clone() will copy the subroutine, but the structure will never be written to at runtime. Other common global variables, such as <code>@EXPORT</code> and <code>%EXPORT_OK</code> are built at compile time and never modified during runtime.</p>
<p>Clearly it would be a big win if XSUBs and such global variables were not copied. However, we do not want to introduce locking of these structures for performance reasons. Perl already supports the concept of a read-only variable, a flag which is checked whenever a Perl variable will be written to. A patch has been submitted to the Perl development track to support a feature known as <code>GvSHARED</code>. This mechanism allows XSUBs and global variables to be marked as shared, so perl_clone() will not copy these structures, but rather point to them.</p>
<h2 id="Shared-SvPVX">Shared SvPVX</h2>
<p>The string slot of a Perl scalar is known as the <code>SvPVX</code>. As Perl typically manages the string a variable points to, it must make a copy of it. However, it is often the case that these strings are never written to. It would be possible to implement copy-on-write strings in the Perl core with little performance overhead.</p>
<h2 id="Compile-time-method-lookups">Compile-time method lookups</h2>
<p>A known disadvantage to Perl method calls is that they are slower than direct function calls. It is possible to resolve method calls at compile time, rather than runtime, making method calls just as fast as subroutine calls. However, there is certain information required for method look ups that are only known at runtime. To work around this, compile-time hints can be used, for example:</p>
<pre><code> my Apache2::Request $r = shift;</code></pre>
<p>Tells the Perl compiler to expect an object in the <code>Apache2::Request</code> class to be assigned to <code>$r</code>. A patch has already been submitted to use this information so method calls can be resolved at compile time. However, the implementation does not take into account sub-classing of the typed object. Since the mod_perl API consists mainly of methods, it would be advantageous to re-visit the patch to find an acceptable solution.</p>
<h2 id="Memory-management-hooks">Memory management hooks</h2>
<p>Perl has its own memory management system, implemented in terms of <i>malloc</i> and <i>free</i>. As an optimization, Perl will hang onto allocations made for variables, for example, the string slot of a scalar variable. If a variable is assigned, for example, a 5k chunk of HTML, Perl will not release that memory unless the variable is explicitly <i>undef</i>ed. It would be possible to modify Perl in such a way that the management of these strings are pluggable, and Perl could be made to allocate from an APR memory pool. Such a feature would maintain the optimization Perl attempts (to avoid malloc/free), but would greatly reduce the process size as pool resources are able to be re-used elsewhere.</p>
<h2 id="Opcode-hooks">Opcode hooks</h2>
<p>Perl already has internal hooks for optimizing opcode trees (syntax tree). It would be quite possible for extensions to add their own optimizations if these hooks were plugable, for example, optimizing calls to <i>print</i>, so they directly call the Apache <i>ap_rwrite</i> function, rather than proxy via a <i>tied filehandle</i>.</p>
<p>Another optimization that was implemented is "inlined" XSUB calls. Perl has a generic opcode for calling subroutines, one which does not know the number of arguments coming into and being passed out of a subroutine. As the majority of mod_perl API methods have known in/out argument lists, mod_perl implements a much faster version of the Perl <i>pp_entersub</i> routine.</p>
<h1 id="Maintainers">Maintainers</h1>
<p>Maintainer is the person(s) you should contact with updates, corrections and patches.</p>
<p>Doug MacEachern <dougm (at) covalent.net></p>
<h1 id="Authors">Authors</h1>
<ul>
<li><p>Doug MacEachern <dougm (at) covalent.net></p>
</li>
</ul>
<p>Only the major authors are listed above. For contributors see the Changes file.</p>
</body>
</html>
|