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.
Some upcoming changes like https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg
will make it somewhat inconvenient to determine whether a given
function invocation will generate a diagnostic. Rather than trying
to exclude this in advance, call the function with diagnostics
suppressed, and check whether anything was thrown.
This adds a new EG flag that is kept specific to the SCCP use-case.
This does not use the error_cb hook as it is a (non-TLS) global,
and doesn't fully suppress error handling besides.
Test this by removing the in advance checks for implode and array_flip.
Avoid the overhead of a call and checking types
when the argument is definitely an array.
Avoid the overhead of gc when `__destruct` won't get called.
This seemed cheap enough to check for in the jit.
Because of https://wiki.php.net/rfc/restrict_globals_usage
we can be sure in the ZEND_COUNT handler that the array count does not have to
be recomputed in php 8.1.
The below example took 0.854 seconds before the optimization,
and 0.564 seconds after the optimization, giving the same result
```php
<?php
/** @jit */
function bench_count(int $n): int {
$total = 0;
$arr = [];
for ($i = 0; $i < $n; $i++) {
$arr[] = $i;
$total += count($arr);
}
return $total;
}
function main() {
$n = 1000;
$iterations = 50000;
$start = microtime(true);
$result = 0;
for ($i = 0; $i < $iterations; $i++) {
$result += bench_count($n);
}
$elapsed = microtime(true) - $start;
printf("Total for n=%d, iterations=%d = %d, elapsed=%.3f\n", $n, $iterations, $result, $elapsed);
}
main();
```
Before
```asm
mov $0x7feb8cf8a858, %r15
mov $ZEND_COUNT_SPEC_CV_UNUSED_HANDLER, %rax
call *%rax
```
After
```asm
mov 0x70(%r14), %rdi - Copy the count from the `zend_array*` pointer
mov %rdi, (%rax) - Store the count in the destination's value
mov $0x4, 0x8(%rax) - Store IS_LONG(4) in the destination's type
```
And add tracing jit support
Closes GH-5584
This is a new transparent technology that eliminates overhead of PHP class inheritance.
PHP classes are compiled and cached (by opcahce) separately, however their "linking" was done at run-time - on each request. The process of "linking" may involve a number of compatibility checks and borrowing methods/properties/constants form parent and traits. This takes significant time, but the result is the same on each request.
Inheritance Cache performs "linking" for unique set of all the depending classes (parent, interfaces, traits, property types, method types involved into compatibility checks) once and stores result in opcache shared memory. As a part of the this patch, I removed limitations for immutable classes (unresolved constants, typed properties and covariant type checks). So now all classes stored in opcache are "immutable". They may be lazily loaded into process memory, if necessary, but this usually occurs just once (on first linking).
The patch shows 8% improvement on Symphony "Hello World" app.
This only moves the files, adjusts the build system, exports APIs
and does minor fixups to make sure the code builds.
This does not yet try to make the optimizer usable independently
of opcache.
Closes GH-6642.
This function tests if an array contains only sequential integer keys. While
list isn't an official type, this usage is consistent with the community usage
of "list" as an annotation type, cf.
https://psalm.dev/docs/annotating_code/type_syntax/array_types/#lists
Rebased and modified version of #4886
- Use .stub.php files
- Add opcache constant evaluation when argument is a constant
- Change from is_list(mixed $value) to array_is_list(array $array)
RFC: https://wiki.php.net/rfc/is_list
Co-Authored-By: Tyson Andre <tysonandre775@hotmail.com>
Co-Authored-By: Dusk <dusk@woofle.net>
Closes GH-6070
The extension name should match the name of the ext/ directory,
otherwise it will not get picked up by run-tests. It would be possible
to remap this in run-tests, but I think it's better to rename the
extension to follow the standard format. Other extensions also
use underscore instead of hyphen (e.g. pdo_mysql and not pdo-mysql).
Of course, the ./configure option remains hyphenated.
Closes GH-6613.
When one thread tries to compile a script, another thread may
already be executing JITed code. In this case we can't make the
memory non-executable.
This violates the W^X principle, but doesn't seem to be avoidable
for ZTS builds for now. The same problem does not exist for NTS,
as it's a different process executing there, which has it's own
memory protection mapping.
Closes GH-6595.
