This is allowed as per the return types RFC. The test for this
behavior happened to use an internal class without arginfo, which
is why this was not properly implemented.
actually, maybe we should precalculate before calling zend_hash_appen
when we are not sure whether the hash is caclculated(prop_info->name).
but it looks a little ugly.. (also for zend_string_copy)
the main idea - the smaller the zend_op structure, the lees memory traffic is required to load VM instructions during execution. The patch reduces the size of each opcode from 48 to 32 bytes (saves 16 bytes for each opcode, and applications use thousands of opoceds). This reduced the number of CPU cache misses by 12% and improved performance of real-life apps by 1-2%.
The patch affects how constants and jump targets are represented in VM during execution. Previously they were implemented as absolute 64-bit pointers. Now they are relative 32-bit offsets.
In run-time constant now should be accessed as:
RT_CONSTANT(op_array, opine->op1) instead of opline->op1.zv
EX_CONSTANT(opline->op1) instead of opline->op1.zv
Jump targets:
OP_JMP_ADDR(opline, opline->op2) instead of opline->op2.jmp_addr
The patch doesn't change zend_op representation for 32-bit systems. They still use absolute addresses. The compile-time representation is also kept the same.
This moves handling of inheritance and interface implementation
from zend_compile.c into a separate zend_inheritance.c file, as
this is not really related to compilation.
