Nikita Popov [Thu, 31 Oct 2019 10:27:53 +0000 (11:27 +0100)]
Remove configure checks for supported instruction sets
These were checking whether the instruction set is supported by
the host CPU, however they were only used to condition on whether
this instruction set is targeted at all. It would still use dynamic
dispatch (e.g. based on ifunc resolvers) to select the actual
implementation. Whether the target is guaranteed to support the
instruction set without dispatch is determined based on pre-defined
macros like __SSE2__.
This removes the configure-time builtin cpu checks to remove
confusion. Additionally this allows targeting an architecture that
is newer than the host architecture.
Nikita Popov [Wed, 30 Oct 2019 12:15:05 +0000 (13:15 +0100)]
Fix bug #77930: Remove mmap limit
First, the limitation already doesn't trigger if you copy the whole
file (i.e. use copy() or stream_copy_to_stream() and don't specify
a length). This happens because length will be 0 at the time of the
check and only later calculated based on the file size. This means
that we're already completely blowing the length limit for what is
likely the most common case, and it doesn't seem like anyone complained
about that.
Second, the premise of the code comment ("to avoid runaway swapping")
seems incorrect to me. Because this performs a file-backed non-private
mmap, no swap backing is needed for the mapping. Concerns over "memory
usage" are also misplaced, as this is a virtual mapping.
Tyson Andre [Fri, 25 Oct 2019 23:57:39 +0000 (19:57 -0400)]
Optimize creation of empty arrays in json_decode
Use the shared empty array from ZVAL_EMPTY_ARRAY
For code that created an 10 arrays of 100000 empty arrays
(has the same result with `$assoc=true` and `{}`)
- This is the worst-case comparison, but I'd expect 0-length arrays to be fairly
common in regular data for json_decode
- The parser implementation was using function pointers so that third party
extension developers could reuse the json parser for their own
data structures, etc. (I think).
This PR is meant to let those third party extensions continue working
without changes.
Before this patch: In 0.126 seconds: added 97.99 MiB
After this patch: In 0.096 seconds: added 41.99 MiB
```php
<?php
$json = '[' . str_repeat('[],', 100000) . "null]";
$start_memory = memory_get_usage();
$start_time = microtime(true);
$result = [];
for ($i = 0; $i < 10; $i++) {
$result[] = json_decode($json);
}
$end_memory = memory_get_usage();
$end_time = microtime(true);
// Before this patch: In 0.126 seconds: added 97.99 MiB
// After this patch: In 0.096 seconds: added 41.99 MiB
printf("In %.3f seconds: added %.2f MiB\n", $end_time - $start_time, ($end_memory - $start_memory)/1000000);
// For objects
$json = '[' . str_repeat('{},', 100000) . "null]";
$start_memory = memory_get_usage();
$start_time = microtime(true);
for ($i = 0; $i < 10; $i++) {
$result[] = json_decode($json, true);
}
$end_memory = memory_get_usage();
$end_time = microtime(true);
// Before this patch: In 0.126 seconds: added 97.99 MiB
// After this patch: In 0.096 seconds: added 41.99 MiB
printf("In %.3f seconds: added %.2f MiB (objects decoded as arrays) \n", $end_time - $start_time, ($end_memory - $start_memory)/1000000);
```
Implement #78270: Support __vectorcall convention with FFI
To work around the limitation of the current rudimentary vectorcall
support in our patched libffi, we forbid yet unsupported declarations,
i.e. float/double parameters at certain positions (SIMD vector types
and HVA types are not supported anyway).
When getting the properties of a DatePeriod instance we have to retain
the proper classes, and when restoring a DatePeriod instance we have to
cater to DateTimeImmutable instances as well.
Nikita Popov [Sun, 27 Oct 2019 08:33:46 +0000 (09:33 +0100)]
Try one more FD in ext/standard/tests/file/php_fd_wrapper_04.phpt
For some reason FD 120 seems to exist on macos quite often, while
FD 12 did not... Let's try an even larger number, otherwise we
should just drop this test.
Nikita Popov [Thu, 24 Oct 2019 14:36:25 +0000 (16:36 +0200)]
Fix bug #78226: Don't call __set() on uninitialized typed properties
Assigning to an uninitialized typed property will no longer trigger
a call to __set(). However, calls to __set() are still triggered if
the property is explicitly unset().
This gives us both the behavior people generally expect, and still
allows ORMs to do lazy initialization by unsetting properties.
For PHP 8, we should fine a way to forbid unsetting of declared
properties entirely, and provide a different way to achieve lazy
initialization.
Nikita Popov [Fri, 25 Oct 2019 09:24:32 +0000 (11:24 +0200)]
Check class linking in VERIFY_RETURN_TYPE optimization
instanceof_function() requires linked classes. I'm not reusing
unlinked_instanceof() here, because it performs class loading,
which wouldn't be right here, I think.
Nikita Popov [Thu, 24 Oct 2019 16:11:41 +0000 (18:11 +0200)]
Remove recursive check from instanceof_interface
Parent interfaces are copied into the interface list during
inheritance, so there's no need to perform a recursive check.
Only exception are instanceof checks performed during inheritance
itself. However, we already have unlinked_instanceof for this
purpose, it just needs to be taught to handle this case.
Nikita Popov [Thu, 24 Oct 2019 15:47:35 +0000 (17:47 +0200)]
Optimize instanceof_class/interface
instanceof_class does not need to check for a NULL pointer in the
first iteration -- passing NULL to this function is illegal.
instanceof_interface does not need to use instanceof_class(), it
only has to check whether the CEs match exactly. There is no way
for an interface to appear inside "parent", it will always be in
"interfaces" only.
Nikita Popov [Thu, 24 Oct 2019 12:41:05 +0000 (14:41 +0200)]
Skip IntlTimeZone::getOffset() error tests on non-x86
I'm not totally sure, but I have a strong suspicion that the fact
that this produces an error is an artifact of undefined cast behavior
(which will yield INDVAL on x86 but saturate on ARM). INF seems to
be the only value that results in an error even on x86 (variations
like -INF or NAN succeed).
It might make sense to just remove this test entirely, but for now
let's skip it on non-x86.
Nikita Popov [Thu, 24 Oct 2019 12:26:17 +0000 (14:26 +0200)]
Don't test "blocks" in lstat_stat_variation7.phpt
This stat property seems to be somewhat unreliable depending on the
filesystem. On Travis ARM64 CI a much larger payload is required
to get this value to increase.
Nikita Popov [Wed, 23 Oct 2019 10:19:33 +0000 (12:19 +0200)]
Don't autoload when checking property types
Noticed while working on union types: We do not load argument and
return types during type checks, but we do load property types.
I'm normalizing the behavior towards the existing status quo (not
loading), though we may consider loading everywhere (all types,
and instanceof) in order to properly support class aliases.
Maksim Nikulin [Wed, 24 Jul 2019 09:50:57 +0000 (16:50 +0700)]
Block signals during fpm master initialization
Fix PHP-FPM failure in the case of concurrent reload attempts.
Postpone signal delivery to the fpm master process till proper signal
handlers are set. Prevent the following case:
- Running master process receives `SIGUSR2` and performs `execvp()`.
- Another `SIGUSR2` is arrived before signal handlers are set.
- Master process dies.
- Requests to the HTTP server handled by PHP-fpm can not be served
any more.
Block some signals using `sigprocmask()` before `execvp()` and early
in the `main()` function. Unblock signals as soon as proper
handlers are set.
projects / php / log