In my local performance testing, function JIT/arm64 failed for wordpress
benchmark after commit d4ed6b6 (including the follow-up fix commit
487efac).
The root cause lies in that immediate encoding for ADD instruction is
unsafe. In this patch, we use the safe macro ADD_SUB_64_WITH_CONST_32.
Besides, safe macro MEM_ACCESS_64_WITH_UOFFSET is used for the two sites
where `opline->result.num` is used as the offset to access memory.
Change-Id: I4704ff27e9527e70061046d634652600e55ccc4f
We can't drop the ASSIGN entirely, but we should mark the result
as UNUSED. Otherwise we'll replace uses of it in operands and
will not free the ASSIGN result value. This can happen with
non-interned strings, but possibly there's some other cases that
can trigger this as well.
This can occur on opcache OOM conditions, where the function/class
names are not interned and the script does not get cached. In
that case the functions/classes get transferred from the persistent
script to the global tables, without incrementing the key refcount.
To mirror that, we should also not try to free the keys when freeing
the persistent script. For this by setting the number of elements
to zero, which will free only the hashtable structure itself.
offsetSet did not account for the fact that the array may no longer exist after
the field is overwritten. This fixes that.
Add test of resizing both to the empty array and a smaller array - there should
be no valgrind warnings with a proper fix.
Alternate approach to #7486 (described in https://bugs.php.net/bug.php?id=81429)
The evaluation of the initializer may throw. This could be refined
by checking whether the initializer is a constant AST. For now
just fix the miscompile.
The do_fcall opcode may have been optimized away if an opcode like
exit is present in the arguments. In that case the opcode scan
would go past the end of the op array.
Ensure current_observed_frame always points to an actually observed frame.
This solution has a caveat of being O(stack size), with the worst case occurring if there are a lot of frames between the current and previous observed frames.
An O(1) solution would require keeping track of the previous observed frame, which would require some additional frame attached metadata, which is best not attempted in an already released version.
Permanent opcache interned strings could have ce_cache pointing to
non-permanent map_ptr slots. On reset, those would be left dangling.
Clear any non-permanent ce_cache slots when the interned string
state is reset.
This was fun to debug...
We should report the undefined variable here and convert it to
null. Passing on undef is particularly insidious here, because
a write_dimension handler may insert it into a hash table
(observed with WeakMap).
PHP JIT supports three configurations: HYRBID, CALL with global register
variables feature(CALL+GRV for short), and CALL+noGRV.
CALL+GRV mode can be built with the following commands:
```
php Zend/zend_vm_gen.php --with-vm-kind=CALL
./buildconf -f; ./configure; make
```
About 230 test cases failed for tracing JIT under CALL+GRV mode on both
x86 and arm64 machines.
For CALL+GRV mode, the condition to determine whether the execution of
an oparray is finished, is "opline == NULL". See function execute_ex()
around line "if (UNEXPECTED(!OPLINE)) {".
However, such cleanup operation is missing for the JIT wrapper
zend_jit_trace_counter_helper(), and the trace_halt stub function.
Tests:
1. test cases: all .phpt test cases under "Zend/tests/ tests/
ext/opcache/tests/jit/".
2. both JIT/x86 and JIT/arm64: function JIT, tracing JIT and tracing JIT
with "--repeat 3"
3. execution modes: NTS/ZTS, HYBRID/CALL+GRV/CALL+noGRV
In my local test, these test cases passed under all JIT configrations.
Don't treat "readonly" as a keyword if followed by "(". This
allows using it as a global function name. In particular, this
function has been used by WordPress.
This does not allow other uses of "readonly", in particular it
cannot be used as a class name, unlike "enum". The reason is that
we'd still have to recognize it as a keyword when using in a type
position:
class Test {
public ReadOnly $foo;
}
This should now be interpreted as a readonly property, not as a
read-write property with type `ReadOnly`. As such, a class with
name `ReadOnly`, while unambiguous in most other circumstances,
would not be usable as property or parameter type. For that
reason, we do not support it at all.
When legacy arginfo is generated, all the type info gets lost. Since this task is performed before any other additional functionalities of gen_stub.php (e.g. verification, method synopsis and class synopsis generation), these fail as they would require the missing type information.
The issue is fixed by deep cloning the file info objects (albeit only their affected properties), so that we use those for legacy arginfo generation, leaving the original ones untouched.
Dmitry Stogov