# [RFC] Turn gc_collect_cycles into a function pointer - Thread: https://externals.io/message/79413 - Original archive: https://news-web.php.net/php.internals/79413 - Started by Benjamin Eberlei on 2014-12-04T08:30:40+00:00 - Messages: 11 - 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 --- ## #79413 — Benjamin Eberlei — 2014-12-04T08:30:40+00:00 URL: https://externals.io/message/79413#79413 Good morning, This is just a very small change, I propose this RFC for discussion to turn the C function "gc_collect_cycles" into a pointer. https://wiki.php.net/rfc/gc_fn_pointer Composer's garbage collection optimization showed that PHP Profilers fail to capture the dynamics of GC and we need better hooks to make this possible. greetings Benjamin --- ## #79417 — Xinchen Hui — 2014-12-04T09:08:29+00:00 URL: https://externals.io/message/79413#79417 · In reply to: #79413 Hey: > Good morning, > > This is just a very small change, I propose this RFC for discussion to turn > the C function "gc_collect_cycles" into a pointer. yeah, this idea is better than add hardly getimeofday into gc thanks > > https://wiki.php.net/rfc/gc_fn_pointer > > Composer's garbage collection optimization showed that PHP Profilers fail > to capture the dynamics of GC and we need better hooks to make this > possible. > > greetings > Benjamin -- Xinchen Hui @Laruence http://www.laruence.com/ --- ## #79421 — Julien Pauli — 2014-12-04T10:53:47+00:00 URL: https://externals.io/message/79413#79421 · In reply to: #79413 > Good morning, > > This is just a very small change, I propose this RFC for discussion to turn > the C function "gc_collect_cycles" into a pointer. > > https://wiki.php.net/rfc/gc_fn_pointer > > Composer's garbage collection optimization showed that PHP Profilers fail > to capture the dynamics of GC and we need better hooks to make this > possible. There are many other things that could be turned into function pointers to allow extensions to hook. Our hook strategy should be reviewed entirely. Not only GC. If you look at streams, many of them are not overwritable, and some are, but they are missing from the headers file so you may not overwrite them. I suggest we design a wider RFC for PHP7 about what we would be able to hook, and what not (and what is the impact, because the more you hook , the more complex it becomes about bad interactions). This may also include a refactoring in the zend_module_entry and the zend_extension structs. Fe, zend_extension hooks about the op_array could be reworked , I find the op_array_dtor_handler hook misplaced in the chain. zend_module_entry could also benefit from refactoring to have a better knowing of other extensions, and a true dependency manager. Julien Pauli --- ## #79422 — Ferenc Kovacs — 2014-12-04T11:39:39+00:00 URL: https://externals.io/message/79413#79422 · In reply to: #79421 > On Thu, Dec 4, 2014 at 9:30 AM, Benjamin Eberlei > wrote: > > […] > turn > > […] > > There are many other things that could be turned into function > pointers to allow extensions to hook. > Our hook strategy should be reviewed entirely. > > Not only GC. If you look at streams, many of them are not > overwritable, and some are, but they are missing from the headers file > so you may not overwrite them. > > I suggest we design a wider RFC for PHP7 about what we would be able > to hook, and what not (and what is the impact, because the more you > hook , the more complex it becomes about bad interactions). > > This may also include a refactoring in the zend_module_entry and the > zend_extension structs. Fe, zend_extension hooks about the op_array > could be reworked , I find the op_array_dtor_handler hook misplaced in > the chain. > zend_module_entry could also benefit from refactoring to have a better > knowing of other extensions, and a true dependency manager. > > That sounds like a lot of work. +1 if somebody willing to champion that effort, but I wouldn't delay/discard this small improvement on the vague promise that maybe this will be solved as part of a bigger rfc. just my 2 cents ofc. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #79423 — Julien Pauli — 2014-12-04T12:17:35+00:00 URL: https://externals.io/message/79413#79423 · In reply to: #79422 > > > > > […] > > That sounds like a lot of work. > +1 if somebody willing to champion that effort, but I wouldn't delay/discard > this small improvement on the vague promise that maybe this will be solved > as part of a bigger rfc. > just my 2 cents ofc. Yep, but the problem in adding a new hook is that today its for feature A, tomorrow it will be for feature B, etc... There is a risk of lack of consistency between all the ideas, that's why I myself did not propose any single idea in this way, but prefer merging them and propose something more consistent. We could benefit from a new major release to have a more global hooking strategy. Also, as this changes the ABI by publishing a new ZEND_API, we should consider adding this in a major and not in a stable release (even thought that doesnt break the ABI). I agree some ideas may represent more work than others (like a dependency management system for extensions), however, big part of the ideas is just about "what hook to move", "where to", "why" and "what hook to add" (and why). Also, having too many hooks can lead to many problems like extensions incompatibility, something barely taken care of in our module API, but which should as well be redesigned as it doesn't really work that much. Julien.P --- ## #79425 — Julien Pauli — 2014-12-04T13:56:15+00:00 URL: https://externals.io/message/79413#79425 · In reply to: #79423 > > > […] > > Yep, but the problem in adding a new hook is that today its for > feature A, tomorrow it will be for feature B, etc... > There is a risk of lack of consistency between all the ideas, that's > why I myself did not propose any single idea in this way, but prefer > merging them and propose something more consistent. > We could benefit from a new major release to have a more global > hooking strategy. > Also, as this changes the ABI by publishing a new ZEND_API, we should > consider adding this in a major and not in a stable release (even > thought that doesnt break the ABI). > > I agree some ideas may represent more work than others (like a > dependency management system for extensions), however, big part of the > ideas is just about "what hook to move", "where to", "why" and "what > hook to add" (and why). > > Also, having too many hooks can lead to many problems like extensions > incompatibility, something barely taken care of in our module API, but > which should as well be redesigned as it doesn't really work that > much. > > Julien.P For GC and any other function that would need to be overwritten, we may use zend_utility_functions. That would limit the number of exported symbols we publish. I don't know why zend_execute and zend_execute_internal are not part of it though. That would need a refactor to export zend_utility_function as global, and use it in any SAPI (it's actually local to main()). Dmitry, Laruence , any advice ? Julien.Pauli --- ## #79426 — Ferenc Kovacs — 2014-12-04T14:26:06+00:00 URL: https://externals.io/message/79413#79426 · In reply to: #79423 > > > […] > delay/discard > > […] > solved > > […] > > Yep, but the problem in adding a new hook is that today its for > feature A, tomorrow it will be for feature B, etc... > There is a risk of lack of consistency between all the ideas, that's > why I myself did not propose any single idea in this way, but prefer > merging them and propose something more consistent. > We could benefit from a new major release to have a more global > hooking strategy. > Also, as this changes the ABI by publishing a new ZEND_API, we should > consider adding this in a major and not in a stable release (even > thought that doesnt break the ABI). > > I agree some ideas may represent more work than others (like a > dependency management system for extensions), however, big part of the > ideas is just about "what hook to move", "where to", "why" and "what > hook to add" (and why). > > Also, having too many hooks can lead to many problems like extensions > incompatibility, something barely taken care of in our module API, but > which should as well be redesigned as it doesn't really work that > much. > > Julien.P > Those are all solid ideas and I wouldn't go against them if proposed, I'm just a bit afraid that we end up with http://en.wikipedia.org/wiki/Nirvana_fallacy where we reject small ideas on the ground of not being perfect or part of a bigger scheme while we don't have the resources to actually make those bigger schemes a reallity. Let see what the others think though. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #79427 — Benjamin Eberlei — 2014-12-04T15:01:36+00:00 URL: https://externals.io/message/79413#79427 · In reply to: #79426 > > > > > > […] > > Those are all solid ideas and I wouldn't go against them if proposed, I'm > just a bit afraid that we end up with > http://en.wikipedia.org/wiki/Nirvana_fallacy where we reject small ideas > on the ground of not being perfect or part of a bigger scheme while we > don't have the resources to actually make those bigger schemes a reallity. > Let see what the others think though. > I agree, this change makes sense this way and is compatible to the way hooks work right now. This change can be part of the grand refactoring later on. Refactoring the whole extension API is a bit time critical anyways, if we won't find a champion for this in the next days/weeks then it won't happen for 7.0 and then by definition (BC breaks) not for any version in 7.* branch. Expanding the scope of this too much will end up as failure. > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu --- ## #79428 — Chris Wright — 2014-12-04T15:04:13+00:00 URL: https://externals.io/message/79413#79428 · In reply to: #79426 > > > > […] > to > > […] > > Those are all solid ideas and I wouldn't go against them if proposed, I'm > just a bit afraid that we end up with > http://en.wikipedia.org/wiki/Nirvana_fallacy where we reject small ideas > on > the ground of not being perfect or part of a bigger scheme while we don't > have the resources to actually make those bigger schemes a reallity. > Let see what the others think though. > +1 --- ## #79554 — Benjamin Eberlei — 2014-12-11T06:49:46+00:00 URL: https://externals.io/message/79413#79554 · In reply to: #79426 I updated the RFC to include a paragraph on this. The change should be included as-is and then be part of a potential refactoring, should one happen. > > > > > > […] > > Those are all solid ideas and I wouldn't go against them if proposed, I'm > just a bit afraid that we end up with > http://en.wikipedia.org/wiki/Nirvana_fallacy where we reject small ideas > on the ground of not being perfect or part of a bigger scheme while we > don't have the resources to actually make those bigger schemes a reallity. > Let see what the others think though. > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu --- ## #79565 — Pierre Joye — 2014-12-11T08:45:23+00:00 URL: https://externals.io/message/79413#79565 · In reply to: #79427 > > I agree, this change makes sense this way and is compatible to the way > hooks work right now. This change can be part of the grand refactoring > later on. 7.0 is indeed the best time to do it. > Refactoring the whole extension API is a bit time critical anyways, if we > won't find a champion for this in the next days/weeks then it won't happen > for 7.0 and then by definition (BC breaks) not for any version in 7.* > branch. This is not correct. The BC break clause applies only for userland. While we try to avoid big APIs change between x.y and x.y+1, we do allow them. However I worry much more about what we do (not) for userland and some bigger changes internally, those that will be very hard to sell for 7.x. > Expanding the scope of this too much will end up as failure. -- Pierre @pierrejoye | http://www.libgd.org