Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:27446
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.25.124.162 as permitted sender)
To: "'Sara Golemon'" <pollita@php.net>,
	<internals@lists.php.net>
Date: Sun, 14 Jan 2007 20:31:27 -0800
Message-ID: <006b01c7385e$07ea10d0$6500a8c0@zend.2k>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <45AB0207.5080505@php.net>
thread-index: Acc4XP07Nccf2x3WTmeKmCalJlNkwQAAOHGA
Subject: RE: [PHP-DEV] Runtime JIT Proposals
From: andi@zend.com ("Andi Gutmans")
References: <45AB0207.5080505@php.net>

Hi Sara,

Sorry but I wasn't on IRC so I don't quite understand what you're trying to accomplish ;)
Can you please explain? Once I understand what you're trying to accomplish I'll be more than happy to provide feedback to the
options list.

Thanks,

Andi 

> -----Original Message-----
> From: Sara Golemon [mailto:pollita@php.net] 
> Sent: Sunday, January 14, 2007 8:25 PM
> To: internals@lists.php.net
> Subject: [PHP-DEV] Runtime JIT Proposals
> 
> For reasons best left on IRC, it looks like I'll be working 
> on runtime JIT.  To that end, I've come up with a few 
> proposals of varying complexity and feature-set completeness:
> 
> Option 1:
> Dump support for compile-time JIT and replace it with a call 
> at runtime using the same semantics.
> 
> Advantages: No change in the API (well, no further change 
> anyway, Unicode support pretty much guarantees that things 
> will change regardless).
> 
> Disadvantages: Could someone be relying on compile-time JIT 
> for something already?  Maybe activation triggers an action 
> which has to take place prior to script execution?  For what 
> I've seen JIT isn't in heavy use, but my perceptions on the 
> topic aren't definitive.
> 
> 
> Option 2:
> Leave compile-time JIT alone, and add a second callback for 
> runtime JIT.
> 
> Advantages: Doesn't break BC, and offers extensions the 
> chance to know that the code contains autoglobal references 
> without actually having to act on them unless they're needed.
> 
> Disadvantages: Adds to complexity/confusion by having two 
> separate callbacks for essentially the same action.
> 
> 
> Option 3:
> Extend JIT signature with a "stage" parameter to indicate if the JIT 
> trigger is occuring during compile-time or run-time.  The 
> callback can 
> decide when/if it performs processing using current return value 
> disarming semantics.
> 
> 
> Option 4:
> Include fetchtype and subelement during runtime JIT callback allowing 
> JIT callback to only do work necessary to prepare for the read/write 
> call being performed.
> 
> e.g.
> 
> int php_example_jit_callback(int str_type, zstr str, int str_len,
>      int stage, zval *container, int fetch_type, zval *element);
> 
> Where str_type/str/str_len indicate the name of the variable being 
> JITed, stage is one of COMPILETIME or RUNTIME, container is the 
> autoglobal itself.
> Fetch_type is ZEND_FETCH_(DIM_|OBJ_)?_(R|W|RW), and element is the 
> specific property/offset (only applicable for DIM/OBJ 
> fetches, NULL for 
> plain fetch.
> 
> Advantages: Gives maximum flexibility to the implementation.  In the 
> case of http request encoding, it allows the decoder to differentiate 
> between requests for a single element and fetches which want 
> to retreive 
> the entire array (e.g. foreach).
> 
> Disadvantages: Adds a lot of complexity to the fetching of 
> autoglobals 
> and qand effectively doubles the amount of callback work 
> being done for 
> autoglobal objects.  Will also confuse implementers on what the 
> difference between this fetch callback is and the 
> (read|write)_(dimension|property) callbacks used by objects.
> 
> 
> In response to the suggestion to just turn $_REQUEST (et.al.) into 
> objects with overloaded array access, the big danger there is 
> that the 
> following behavior would change:
> 
> $postdata = $_REQUEST;
> foreach($postdata as $idx => $val) {
>    $postdata[$idx] = some_filter_func($val);
> }
> 
> Were $_REQUEST turned into an object with overloaded array 
> access, these 
> changes to $postdata would modify the values in the original 
> $_REQUEST 
> (due to the reference-like behavior of PHP5+ objects).
> 
> 
> Personally, I like Option 4, but then I like complexity.  I can 
> certainly see going for any of the others, but I want to go with 
> something that the rest of the group can see being 
> appropriately useful.
> 
> If I can get something approaching a semi-consensus on 
> direction, I can 
> have an implementation (or a couple, depending on feelings on the 
> matter) in a few days.
> 
> -Sara
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>