# runtime JIT - Thread: https://externals.io/message/28022 - Original archive: https://news-web.php.net/php.internals/28022 - Started by Dmitry Stogov on 2007-02-14T12:07:13+00:00 - Messages: 7 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #28022 — Dmitry Stogov — 2007-02-14T12:07:13+00:00 URL: https://externals.io/message/28022#28022 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 JIT > > > Hi, > > 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. > > > > […] > solution IMO, > > […] > patch put into > > […] --- ## #28025 — Pierre — 2007-02-15T14:22:28+00:00 URL: https://externals.io/message/28022#28025 · In reply to: #28022 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 --- ## #28038 — Andrei Zmievski — 2007-02-15T18:46:51+00:00 URL: https://externals.io/message/28022#28038 · In reply to: #28022 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? --- ## #28040 — Pierre — 2007-02-15T19:10:47+00:00 URL: https://externals.io/message/28022#28040 · In reply to: #28038 > 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 --- ## #28246 — Andrei Zmievski — 2007-03-05T18:04:15+00:00 URL: https://externals.io/message/28022#28246 · In reply to: #28025 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 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 --- ## #28272 — Pierre — 2007-03-06T12:10:20+00:00 URL: https://externals.io/message/28022#28272 · In reply to: #28246 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 --- ## #28973 — Lukas Kahwe Smith — 2007-04-24T12:42:40+00:00 URL: https://externals.io/message/28022#28973 · In reply to: #28272 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.