On 8 April 2024 21:51:46 BST, Jordan LeDoux <jordan.led...@gmail.com> wrote:
>I have mentioned before that my understanding of the deeper aspects of how
>zvals work is very lacking compared to some others, so this is very
>helpful.
My own knowledge definitely has gaps and errors, and comes mostly from
introductions like https://www.phpinternalsbook.com/ and in this case Nikita's
blog articles about the changes in 7.0:
https://www.npopov.com/2015/05/05/Internal-value-representation-in-PHP-7-part-1.html
> I confess that I do not
>understand the technical intricacies of the interned strings and packed
>arrays, I just understand that the zval structure for these arbitrary
>precision values would probably be non-trivial, and from what I was able to
>research and determine that was in part related to the 64bit zval limit.
From previous discussions, I gather that the hardest part of implementing a new
zval type is probably not the memory structure itself - that will mostly be
handled in a few key functions and macros - but the sheer number of places that
do something different with each zval type and will need updating. Searching
for Z_TYPE_P, which is just one of the macros used for that purpose, shows over
200 lines to check:
https://heap.space/search?project=php-src&full=Z_TYPE_P&defs=&refs=&path=&hist=&type=c
That's why it's so much easier to wrap a new type in an object, because then
all of those code paths are considered for you, you just have a fixed set of
handlers to implement. If Ilija's "data classes" proposal progresses, you'll be
able to have copy-on-write for free as well.
Regards,
Rowan Tommins
[IMSoP]
