This handles the degenerate case where SCCP replaced the value in
the RETURN opcode with a constant, but the VERIFY_RETURN is still
there. We can still apply the same optimization, just don't need
to adjust the use list in this case.
The result is still sub-optimal in that a dead QM_ASSIGN is left
behind.
Even if we don't know the exact method being called, include it
in the call graph with the is_prototype flag. In particular, we
can still make use of return types from prototype methods, as
PHP 8 makes LSP violations a hard error.
Most other places are adjusted to skip calls with !is_prototype.
Maybe some of them would be fine, but ignoring them is conservative.
Even if an explicit return type is given, we might still infer
a more narrow one based on return statements. We shouldn't
pessimize this just because a type has been declared.
static_variables should be treated the same way as all other
op_array components nowadays (only static_variables_ptr is
special). There's no need to persist/serialize it is separately
per shared op_array.
It seems that f3efb9e3fb introduced a "typo" which may result
in the following confusing message:
checking for mmap() using MAP_ANON shared memory support... no=yes
Let's fix this.
Signed-off-by: Michael Heimpold <mhei@heimpold.de>
Closes GH-6758.
This issue came up recently in a bug report[1]; without the error code,
users can barely guess why the function failed.
[1] <https://bugs.php.net/80812>
Closes GH-6745.
Currently, dynamically declared functions and closures are inserted
into the function table under a runtime definition key, and then later
possibly renamed. When opcache is not used and a file containing a
closure is repeatedly included, this leads to a very large memory leak,
as the no longer needed closure declarations will never be freed
(https://bugs.php.net/bug.php?id=76982).
With this patch, dynamic functions are instead stored in a
dynamic_func_defs member on the op_array, which opcodes reference
by index. When the parent op_array is destroyed, the dynamic_func_defs
it contains are also destroyed (unless they are stilled used elsewhere,
e.g. because they have been bound, or are used by a live closure). This
resolves the fundamental part of the leak, though doesn't completely
fix it yet due to some arena allocations.
The main non-obvious change here is to static variable handling:
We can't destroy static_variables_ptr in destroy_op_array, as e.g.
that would clear the static variables in a dynamic function when
the op_array containing it is destroyed. Static variable destruction
is separated out for this reason (we already do static variable
destruction separately for normal functions, so we only need to
handle main scripts).
Closes GH-5595.
We already use <= for IS_SERIALIZED(), but the same general
problem can also occur for IS_UNSERIALIZED(). We don't seem to
hit this in practice prior to GH-5595 though.
Don't use r0 as temporary register in math_double_long if it is
already used for a memory result.
This was already done in one branch, but not the other.
When a method is inherited, the static variables will now always
use the initial values, rather than the values at the time of
inheritance. As such, behavior no longer depends on whether
inheritance happens before or after a method has been called.
This is implemented by always keeping static_variables as the
original values, and static_variables_ptr as the modified copy.
Closes GH-6705.
