The motivation for this is that types should be considered immutable.
The only times this is not valid is during compilation, optimizations (opcache), or destruction.
Therefore the "normal" type foreach macros are marked to take const arguments and we add mutable version that say so in the name.
Thus add various const qualifiers to communicate intent.
This avoids repeated lookups in the function table for the same
function name.
Although this optimization is observable, i.e. defining a function via
an include in between 2 JMP_FRAMELESS for the same function, this cannot
be relied on already as far as I know if the optimizer runs.
Rather than using a separate hash table for doubles, use the same
biases hash approach we use for everything else. Either way works
fine, but there doesn't seem to be any strong reason to use a
different approach for doubles than we use for other cases.
This seems to be a leftover from when we were storing cache slots
inside literals and had to prevent merging of literals with
incompatible cache slots. Nowadays the LITERAL_* classification
is not actually used for anything, we're only interested in the
number of related literals.
Nowadays we include the content of all the related literals in the
cache key, so DECLARE_CLASS (where both literals cannot be derived
from each other) no longer needs this special case.
1. Update: http://www.php.net/license/3_01.txt to https, as there is anyway server header "Location:" to https.
2. Update few license 3.0 to 3.01 as 3.0 states "php 5.1.1, 4.1.1, and earlier".
3. In some license comments is "at through the world-wide-web" while most is without "at", so deleted.
4. fixed indentation in some files before |
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.
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 is an annoying edge case that regularly gets broken. As we're
not aware of significant users of this API, and there are other
ways to hook this, remove support for EXT_NOP.
From an engine perspective, named parameters mainly add three
concepts:
* The SEND_* opcodes now accept a CONST op2, which is the
argument name. For now, it is looked up by linear scan and
runtime cached.
* This may leave UNDEF arguments on the stack. To avoid having
to deal with them in other places, a CHECK_UNDEF_ARGS opcode
is used to either replace them with defaults, or error.
* For variadic functions, EX(extra_named_params) are collected
and need to be freed based on ZEND_CALL_HAS_EXTRA_NAMED_PARAMS.
RFC: https://wiki.php.net/rfc/named_params
Closes GH-5357.
According to RFC: https://wiki.php.net/rfc/union_types_v2
The type representation now makes use of both the pointer payload
and the type mask at the same time. Additionall, zend_type_list is
introduced as a new kind of pointer payload, which is used to store
multiple class types. Each of the class types is a tagged pointer,
which may be either a class name or class entry. The latter is only
used for typed properties, while arguments/returns will instead use
cache slots. A type list can contain a mix of both names and CEs at
the same time, as not all classes may be resolvable.
One thing this is missing is support for union types in arginfo
and stubs, which I want to handle separately.
I've also dropped the special object code from the JIT implementation
for now -- I plan to add this back in a different form at a later time.
For now I did not want to include non-trivial JIT changes together
with large functional changes.
Another possible piece of follow-up work is to implement "iterable"
as an internal alias for "array|Traversable". I believe this will
eliminate quite a few special-cases that had to be implemented.
Closes GH-4838.
LITERAL_VALUE with related literals cannot be merged, avoid inserting
them in the literals hash in the first place. Otherwise we may end up
inserting the same key multiple times. We may also miss merging
opportunities due to the duplicate keys.
Access to undefined constants will now always result in an Error
exception being thrown.
This required quite a few test changes, because there were many
buggy tests that unintentionally used bareword fallback in combination
with error suppression.
The only remaining case-insensitive constants are null, true and
false, which are handled explicitly.
In the future we may convert them from constants to reserved keywords.
RFC: https://wiki.php.net/rfc/typed_properties_v2
This is a squash of PR #3734, which is a squash of PR #3313.
Co-authored-by: Bob Weinand <bobwei9@hotmail.com>
Co-authored-by: Joe Watkins <krakjoe@php.net>
Co-authored-by: Dmitry Stogov <dmitry@zend.com>
The cache size could be off by 4, if we're on a 32-bit system and
the slot had to be bumped for alignment reasons.
I wasn't able to reproduce the issue reported in bug #77287, but I
think this might be the cause.
Instead of juggling with this problem during literal compaction,
make sure that we always initialize Z_EXTRA for literals, which
seems like the more robust solution.
Gina Peter Banyard
Niels Dossche
Ilija Tovilo
Nikita Popov
KsaR
Dmitry Stogov
Zeev Suraski
Peter Kokot