The patch is attached.
To use runtime JIT you will need to change zend_register_auto_global() to
zend_register_auto_global_ex() with "1" as the last argument. Compile-time
JIT is still supported too.
Note that the significant part of the patch is reverting of "autoglobals CV"
patch, that is reimplemented using CG(auto_globals_cache).
Any objections?
Thanks. Dmitry.
-----Original Message-----
From: Dmitry Stogov [mailto:dmitry@zend.com]
Sent: Tuesday, February 13, 2007 10:35 PM
To: 'Sara Golemon'; 'pierre.php@gmail.com'; 'Andrei Zmievski'
Cc: 'Andi Gutmans'; 'Rasmus Lerdorf'
Subject: RE: runtime JITHi,
I see the following simple decision:
PHP compiler compiles accesses to autoglobals into
ZEND_FETCH_x "name" with flag ZEND_FETCH_AUTOGLOBAL instead
of ZEND_FETCH_GLOBAL. Also this opcode contains an index of
autoglobal descriptor (for fast access during execution).During execution of ZEND_FETCH_x with ZEND_FETCH_AUTOGLOBAL,
it looks into autoglobal descriptor, checks if JIT was
already called, and calls autoglobal JIT callback if need.The decision walso removes (or modifys) CV autoglobals patch.
We don't need to mix local and autoglobal CV in one array.
Autoglobals zvals are cached in autoglobal desriptors.Is this OK?
Dmitry.
-----Original Message-----
From: Sara Golemon [mailto:pollita@php.net]
Sent: Tuesday, February 13, 2007 7:14 PM
To: pierre.php@gmail.com
Cc: Dmitry Stogov; Andrei Zmievski; Andi Gutmans; Rasmus Lerdorf
Subject: Re: runtime JITWe've discussed it all a number of times on the list. Do
you have
access to archives?I have, but extracting requirements from the list will take huge
amount of time.
Could you point me into the key problems and ideasKey Problems:
Scripts need an opportunity to do some processing prior
to the GPC
values being decoded to unicode so that the script can specify what
encoding the data is likely to be coming in.Decoding an entire GPC array at once opens the door to potential
attack vectors by injecting deliberately invalid data, so
we'd like to
be able to only decode elements on an as-requested basis (the
also means
less-work for the runtime).Ideas:
Make JIT happen at Runtime (Possibly allowing it to happen on a
per-element basis)Wrap GPC arrays in over-loaded objects. Not a bad
solution IMO,
but not without it's problems. (I've explained the BC issues
surrounding
this too many times to do it again)JIT is now done at compile time, it has to be done at
runtime instead.
That's the key problem/change. What do you mean by "good way"?I presume he's referring to the numerous hooks my last
patch put into
the various FETCH ops as a not-good way. Taking the per-element
component out of the picture would reduce that somewhat, but
the need to
catch all the various fetches would still exist.-Sara
Hi Dmitry!
The patch is attached.
To use runtime JIT you will need to change zend_register_auto_global() to
zend_register_auto_global_ex() with "1" as the last argument. Compile-time
JIT is still supported too.Note that the significant part of the patch is reverting of "autoglobals CV"
patch, that is reimplemented using CG(auto_globals_cache).Any objections?
The patch looks good and it implements the concept I described in my
initial proposal. So no, no objection here.
For the record, what needs to be done now is (after a short discussion
with Dmitry):
- implement the callback to decode the input
- support multiple calls of http_input_encoding, GPC must be
re-encoded (rearm JIT)
a new function is required and a couple of changes in the hash
creations (call dtor, etc.) - Add test cases
- Implement unicode support in ext/filter
I do not have the time to test and work on that until next week on
Wednesday. If someone likes to work on one part or another, please
raise the hand :)
Thanks for your work!
--Pierre
Pierre,
How's it going with this list you posted? Last I heard you had some
issues with ext/session. Can you elaborate please?
-Andrei
Hi Dmitry!
The patch is attached.
To use runtime JIT you will need to change
zend_register_auto_global() to
zend_register_auto_global_ex() with "1" as the last argument.
Compile-time
JIT is still supported too.Note that the significant part of the patch is reverting of
"autoglobals CV"
patch, that is reimplemented using CG(auto_globals_cache).Any objections?
The patch looks good and it implements the concept I described in my
initial proposal. So no, no objection here.For the record, what needs to be done now is (after a short discussion
with Dmitry):
- implement the callback to decode the input
- support multiple calls of http_input_encoding, GPC must be
re-encoded (rearm JIT)
a new function is required and a couple of changes in the hash
creations (call dtor, etc.)- Add test cases
- Implement unicode support in ext/filter
I do not have the time to test and work on that until next week on
Wednesday. If someone likes to work on one part or another, please
raise the hand :)Thanks for your work!
--Pierre
Hi Andrei,
Pierre,
How's it going with this list you posted? Last I heard you had some
issues with ext/session. Can you elaborate please?
The issue is not specifically with the ext/session but with extensions
accessing the input data during RINIT. For example, ext/session tries
to access the HTTP input to fetch a possible SESSID.
To keep the JIT at runtime only I like to add an internals API to
access the input value as raw/binary data, without decoding them. It
will be the responsibility of the extension to correctly decode the
data.
It would be possible to implement JIT in each extension, but as soon
as the script uses a different encoding than the extension (which is
defined by http.input_encoding or another specific php.ini option), we
will have to decode the complete input two times (or more on error).
I'm reviewing the other extension for the http_globals usage. I will
come with the API and the patch as soon as possible.
Cheers,
--Pierre
Hello,
From my understanding the main thing that is holding back a first
preview/alpha release of PHP6 is solving the below explained issues in
the JIT parameter handling. Pierre and Dmitry were the two most likely
candidates to implement this, but I guess both of them are busy (?).
Maybe someone else feels capable of taking over this task for them?
regards,
Lukas
Pierre wrote:
The issue is not specifically with the ext/session but with extensions
accessing the input data during RINIT. For example, ext/session tries
to access the HTTP input to fetch a possible SESSID.To keep the JIT at runtime only I like to add an internals API to
access the input value as raw/binary data, without decoding them. It
will be the responsibility of the extension to correctly decode the
data.It would be possible to implement JIT in each extension, but as soon
as the script uses a different encoding than the extension (which is
defined by http.input_encoding or another specific php.ini option), we
will have to decode the complete input two times (or more on error).I'm reviewing the other extension for the http_globals usage. I will
come with the API and the patch as soon as possible.
Just to be clear: does this implement runtime JIT per-element or for
the whole array at once?
-Andrei
The patch is attached.
To use runtime JIT you will need to change zend_register_auto_global()
to
zend_register_auto_global_ex() with "1" as the last argument.
Compile-time
JIT is still supported too.Note that the significant part of the patch is reverting of
"autoglobals CV"
patch, that is reimplemented using CG(auto_globals_cache).Any objections?
Just to be clear: does this implement runtime JIT per-element or for
the whole array at once?
The whole array. It is exactly like what we have now for the compile-time JIT.
--Pierre