Store default object handlers alongside the class entry

[bwoebi]

Object handlers being separate from class entries is a legacy inherited from PHP 5. Today it has little benefit to keep them separate: in fact, accessing object handlers usually requires not-so-safe hacks.
While it is possible to swap handlers in a custom installed create_object handler, this mostly is tedious, as well as it requires allocating the object handlers struct at runtime, possibly caching it etc..

This allows extensions, which intend to observe other classes to install their own class handlers.
The life cycle of internal classes may now be simply observed by swapping the class handlers in post_startup stage.
The life cycle of userland classes may be observed by iterating over the new classes in zend_compile_file and zend_compile_string and then swapping their handlers.

In general, this would also be a first step in directly tying the object handlers to classes (i.e., removing the handlers field from zend_object). Especially given that I am not aware of any case where the object handlers would be different between various instances of a given class.

This PR (for now) only changes occurrences in Zend. Once the general approach is approved, I will update all other occurrences in ext/ as well.

[Girgias]

The general approach makes sense to me.

I wonder if at one point it would be possible to merge the object handlers with the various zend_function* used for userland implementation of magic methods, but that looks hard TM and not immediately beneficial.

[bwoebi]

This probably makes some sense as part of a long-term effort to use the C stack less and have proper zend_functions for much more things. However not every handler has equivalent magic methods (e.g. free_obj).

[iluuu1994]

@bwoebi Does this also mean the handlers can't be changed once the class is already in shared memory? An extension like Xdebug or Blackfire might only want to override certain handlers for certain requests (e.g. when a header is set) to avoid slowdowns when the page is not being profiled. This would mean we'd likely also need to store the handlers in zend_class_mutable_data which would further complicate accessing it.

Disclaimer: I have no clue how Xdebug/Blackfire do things. They might also fall back to the std handlers internally in which case this would be less of a problem.

[bwoebi]

@iluuu1994 This, for now, does not impact the currently available capabilities. For now I'm just inserting the class handlers at ce creation directly into the ce, and then copying from the ce to the object at runtime. Instead of the create_object callback having to set the handlers on the object. The status quo of object handlers existing on the object is untouched. It should not impact any extensions trying to do things.

[iluuu1994]

@bwoebi But it would once we removed zend_object.handlers, right? Maybe @derickr and somebody from Blackfire could answer if this this would be a problem for their case. Other than that, this would add an indirection when the class isn't loaded yet with a potential cache miss but that's likely not a problem because invoking any handler will likely involve fetching the class anyway- Still, it might make sense to profile this once we make that step. Other than that it definitely makes more sense to keep this on the class, because as you said they are basically always the same for the same types of objects.

[bwoebi]

Yes, it would. Hence I'm projecting this to future scope as this needs more investigation / a transition period and I'm not doing it straight away.

[bwoebi]

I think we should avoid labeling extensions when > 5 extensions are affected... That's just funny and useless.

[derickr]

As this seems to be done for every single class, wouldn't it make more sense to have the arg stubs parser/code generate do this automatically in the register_class_DatePeriod (and friends) code that it generates?

[bwoebi]

But how would the stubs know whether there are handlers for the object? Some classes don't need handlers and some do inherit them from their parent.

[derickr]

And to answer @iluuu1994 's question - it doesn't seem that @xdebug uses these object handlers for anything.

[krakjoe]

From a hacking-the-engine-a-la-uopz-or-runkit point of view, I like this approach and think the future scope is worth working toward, so +1 from me.