Not sure if this is possible to hit in practice, zend_accel_error_noreturn
doesn't return so the unlock isn't called. Other callsites that use both
zend_accel_error_noreturn and zend_shared_alloc_unlock first perform the
unlocking.
Closes GH-11718.
If opcache isn't loaded, then opcache_invalidate() will fail.
Reproducible when you compile PHP without opcache, or run PHP without
opcache loaded, and try to run this test.
Closes GH-11378.
This merges all usages of emitting an offset TypeError into a new ZEND_API function
zend_illegal_container_offset(const zend_string* container, const zval *offset, int type);
Where the container should represent the type on which the access is attempted (e.g. string, array)
The offset zval that is used, where the error message will display its type
The type of access, which should be a BP_VAR_* constant, to get special message for isset/empty/unset
* PHP-8.2:
Fix DOMElement::append() and DOMElement::prepend() hierarchy checks
Fix spec compliance error for DOMDocument::getElementsByTagNameNS
Fix GH-11336: php still tries to unlock the shared memory ZendSem with opcache.file_cache_only=1 but it was never locked
Fix GH-11338: SplFileInfo empty getBasename with more than one slash
* PHP-8.1:
Fix DOMElement::append() and DOMElement::prepend() hierarchy checks
Fix spec compliance error for DOMDocument::getElementsByTagNameNS
Fix GH-11336: php still tries to unlock the shared memory ZendSem with opcache.file_cache_only=1 but it was never locked
Fix GH-11338: SplFileInfo empty getBasename with more than one slash
I chose to check for the value of lock_file instead of checking the
file_cache_only, because it is probably a little bit faster and we're
going to access the lock_file variable anyway. It's also more generic.
Closes GH-11341.
The function repeatedly calls mprotect() which is extremely slow. In our
community build, the Laravel tests went from ~6 minutes to ~4 hours. This issue
only occurs with opcache.protect_memory=1.
Closes GH-11323
The break is outside the if, so if it succeeds or not this will always
stop after the first loop iteration instead of trying more allocators if
the first one fails.
Closes GH-11306.
Avoid missing possible candidates due to the large address range of the free segment.
Eg,
48000000-49400000 r-xs 08000000 00:0f 39322841 segment1
7ffff2ec8000-7ffff2f49000 rw-p 00000000 00:00 0 segment2
7ffff6fae000-7ffff735c000 r-xp 00200000 08:02 11538515 /usr/local/sbin/php-fpm
original code will miss the opportunity between [7ffff2ec** - 7ffff2ec8000].
Fix issue #11265.
Signed-off-by: Long, Tao <tao.long@intel.com>
Signed-off-by: Dmitry Stogov <dmitrystogov@gmail.com>
The block optimizer pass allows the use of sources of the preceding
block if the block is a follower and not a target. This causes issues
when trying to remove FREE instructions: if the source is not in the
block of the FREE, then the FREE and source are still removed. Therefore
the other successor blocks, which must consume or FREE the temporary,
will still contain the FREE opline. This opline will now refer to a
temporary that doesn't exist anymore, which most of the time results in
a crash. For these kind of non-local scenarios, we'll let the SSA
based optimizations handle those cases.
Closes GH-11251.
Normally, we add classes without parents (and no interfaces or traits) directly
to the class map, early binding the class. However, if the same class has
already been registered, we would instead just add a ZEND_DECLARE_CLASS
instruction and let the handler throw a duplicate class declaration exception.
However, with opcache, if on the next request the files are included in the
opposite order, we won't perform early binding. To fix this, create a
ZEND_DECLARE_CLASS_DELAYED instruction instead and handle classes without
parents accordingly, skipping any linking for classes that are already linked in
delayed early binding.
Fixes GH-8846
Once code is emitted to JIT buffer, hint the hardware to
demote the corresponding cache lines to more distant level
so other CPUs can access them more quickly.
This gets nearly 1% performance gain on our workload.
Signed-off-by: Xue,Wang <xue1.wang@intel.com>
Signed-off-by: Tao,Su <tao.su@intel.com>
Signed-off-by: Hu,chen <hu1.chen@intel.com>
If we bind the class to the runtime slot even if we're not the ones who have
performed early binding we'll miss the redeclaration error in the
ZEND_DECLARE_CLASS_DELAYED handler.
Closes GH-11226
There is a typo which causes the AND and OR range inference to infer a
wider range than necessary. Fix this typo. There are many ranges for
which the inference is too wide, I just picked one for AND and one for
OR that I found through symbolic execution.
In this example test, the previous range inferred for test_or was [-27..-1]
instead of [-20..-1].
And the previous range inferred for test_and was [-32..-25]
instead of [-28..-25].
Closes GH-11170.
Max length of a single trace. A long trace generates long JITTed
code, which influences the performance slightly.
opcache.jit_max_trace_length range is [4,1024], the default value
is 1024.
Reviewed-by: Su, Tao <tao.su@intel.com>
Signed-off-by: Wang, Xue <xue1.wang@intel.com>
