Adjust GC threshold if num_roots is higher than gc_threshold after collection (#13758)

This fixes an edge case causing the GC to be triggered repeatedly.

Destructors might add poten

Adjust GC threshold if num_roots is higher than gc_threshold after collection (#13758)

This fixes an edge case causing the GC to be triggered repeatedly.

Destructors might add potential garbage to the buffer, so it may happen that num_root it higher than gc_threshold after collection, thus triggering a GC run almost immediately. This can happen by touching enough objects in a destructor, e.g. by iterating over an array. If this happens again in the new run, and the threshold is not updated, the GC may be triggered again.

The edge case requires specific conditions to be triggered and it must happen rarely in practice:

* At least GC_THRESHOLD_TRIGGER (100) objects must be collected during each run for the threshold to not be updated
* At least GC_G(gc_threshold) (initially 10k) objects must be touched (decref'ed to n>0) by any destructor during each run to fill the buffer

The fix is to increase the threshold if GC_G(num_roots) >= GC_G(gc_threshold) after GC. The threshold eventually reaches a point at which the second condition is not met anymore.

The included tests trigger more than 200 GC runs before the fix, and 2 after the fix (dtors always trigger a second run).

A related issue is that zend_gc_check_root_tmpvars() may add potential garbage before the threshold is adjusted, which may trigger GC and exhaust the stack. This is fixed by setting GC_G(active)=1 around zend_gc_check_root_tmpvars().

show more ...

Fix GH-13569: GC buffer unnecessarily grows up to GC_MAX_BUF_SIZE when scanning WeakMaps

Fix GH-13193: Significant performance degradation in 'foreach' starting from PHP 8.2.13 (caused by garbage collection) (#13265)

* Fix GH-13193: Significant performance degradation in 'foreac

Fix GH-13193: Significant performance degradation in 'foreach' starting from PHP 8.2.13 (caused by garbage collection) (#13265)

* Fix GH-13193: Significant performance degradation in 'foreach' starting from PHP 8.2.13 (caused by garbage collection)

* Don't run zend_gc_remove_root_tmpvars() if GC is not active or GC buffer is empty

show more ...

Fix memory leak after GC inside a foreach loop (#12572)

Fixes oss-fuzz #54515

Remove WeakMap entries whose key is only reachable through the entry value (#10932)

Expose time spent collecting cycles in gc_status() (#11523)

Fixes "GC_BENCH" is not defined in extensions including zend_gc.h

Compilation warning encountered:

include/php/Zend/zend_gc.h:49:5: warning: "GC_BENCH" is not defined, evaluates to

Fixes "GC_BENCH" is not defined in extensions including zend_gc.h

Compilation warning encountered:

include/php/Zend/zend_gc.h:49:5: warning: "GC_BENCH" is not defined, evaluates to 0 [-Wundef]
49 | #if GC_BENCH
| ^~~~~~~~

show more ...

Fix GC_BENCH flag (#10823)

zend_gc_globals is now hidden, so we can't access it from zend.c.

Fix incorrect UNEXPECTED paren placement in zend_gc.c

Closes GH-10371.

Revert GH-10300

Cf. <https://github.com/php/php-src/pull/10220#issuecomment-1383739816>.

This reverts commit 68ada76f9a659745f572539b72afa06fa75a866f.
his reverts commit 45384c6

Revert GH-10300

Cf. <https://github.com/php/php-src/pull/10220#issuecomment-1383739816>.

This reverts commit 68ada76f9a659745f572539b72afa06fa75a866f.
his reverts commit 45384c6e201eda9963e2fcc18946a9446230a2d6.
This reverts commit ef7fbfd71025f034b0bfcb413efd181ce798fc1b.
This reverts commit 9b9ea0d7c696f2990a159b2a2dafbc04547dc10f.
This reverts commit f15747c26be4a2330dc0cf3ea442f53f30f84cac.
This reverts commit e883ba93c40827fafd7868517eb48e04569f76ab.
This reverts commit 7e87551c3775d26e20b06a4032a00053db6452cc.
This reverts commit 921274d2b8966641a00c0a767ae40ba7187bdffc.
This reverts commit fc1f528e5e3ee45ab17ae8dcfad6a6422ff2002d.
This reverts commit 0961715cdafb5d39124667ff94f3b56453ce71f1.
This reverts commit a93f264526e1cdade71d887800c1c448c411bfdc.
This reverts commit 72dd94e1c6d29203b8f6473317f626e6d6d6fbdc.
This reverts commit 29b2dc89645e741f91cc920964432dccd2aaef14.
This reverts commit 05c7653bba7571852f5ce6fc0d220a1a829bc4c0.
This reverts commit 5190e5c260ee05e3f3c3d1168263a1a6637441d0.
This reverts commit 6b55bf228cb2da8705737d414f394950a92d8aae.
This reverts commit 184b4a12d3215d105720d005b31e365249e2eb21.
This reverts commit 4c31b7888a561e920fd3889ba8d99368f3c2d9e6.
This reverts commit d44e9680f080b4918cfed268b96f90ea35975617.
This reverts commit 4069a5c43f419d76e1254c8e49b4cad9968a408f.

show more ...

Zend/zend_gc: include cleanup

Add four extra fields to gc_status() (#9336)

- running: true if garbage collection is currently running
- protected: true if the garbage collector is protected and root
additions a

Add four extra fields to gc_status() (#9336)

- running: true if garbage collection is currently running
- protected: true if the garbage collector is protected and root
additions are forbidden
- full: true if the garbage collector buffer size exceeds GC_MAX_BUF_SIZE
- buffer_size: current garbage collector buffer size

Documentation for existing fields:

- runs: the number of times the garbage collector has been run
- collected: the number of objects collected
- threshold: the number of roots in the buffer which will trigger
garbage collection
- roots: the current number of roots in the buffer

Updated manual example output:

array(8) {
["running"]=>
bool(false)
["protected"]=>
bool(false)
["full"]=>
bool(false)
["runs"]=>
int(5)
["collected"]=>
int(100002)
["threshold"]=>
int(50001)
["buffer_size"]=>
int(131072)
["roots"]=>
int(0)
}

show more ...

Merge branch 'PHP-8.1'

* PHP-8.1:
Fix GH-9266: GC root buffer keeps growing when dtors are present

Fix GH-9266: GC root buffer keeps growing when dtors are present

Do not reset cleared count on GC rerun.

Closes GH-9265.

Avoid possible [-Wstrict-prototypes] build warnings

Refactor GC data traversal loops

Previusly, to redce stack usage GC traversed object properties and array
elements in both directions. At first, it seeked backward from the last
elem

Refactor GC data traversal loops

Previusly, to redce stack usage GC traversed object properties and array
elements in both directions. At first, it seeked backward from the last
element, to find the last refcounted zval. Then, it traversed elements
forward. As result, we had 2 non-spatial memory accesses for each
object/array and usuall 2 expensive CPU cache misses.

Now all the traversal algorithms are refactored to scan elements only in
forward direction. The number of checks and GC stack usage should be the
same. The order of element processing may be differenr, but this
should not be a problem.

show more ...

Use more compact representation for packed arrays.

- for packed arrays we store just an array of zvals without keys.
- the elements of packed array are accessible throuf as ht->arPacked[

Use more compact representation for packed arrays.

- for packed arrays we store just an array of zvals without keys.
- the elements of packed array are accessible throuf as ht->arPacked[i]
instead of ht->arData[i]
- in addition to general ZEND_HASH_FOREACH_* macros, we introduced similar
familied for packed (ZEND_HASH_PACKED_FORECH_*) and real hashes
(ZEND_HASH_MAP_FOREACH_*)
- introduced an additional family of macros to access elements of array
(packed or real hashes) ZEND_ARRAY_ELEMET_SIZE, ZEND_ARRAY_ELEMET_EX,
ZEND_ARRAY_ELEMET, ZEND_ARRAY_NEXT_ELEMENT, ZEND_ARRAY_PREV_ELEMENT
- zend_hash_minmax() prototype was changed to compare only values

Because of smaller data set, this patch may show performance improvement
on some apps and benchmarks that use packed arrays. (~1% on PHP-Parser)

TODO:
- sapi/phpdbg needs special support for packed arrays (WATCH_ON_BUCKET).
- zend_hash_sort_ex() may require converting packed arrays to hash.

show more ...

Fix some typos (#7320)

Clean up gc_scan() implementation

The HT handling no longer needs to be shared, so move it into the
right branch. Also use a couple of early gotos to reduce nesting.

Fix GC of object properties HT

We partially fixed this in bug #78379, but still don't handle
the case where the properties array is marked as grey first,
which causes a delref to not

Fix GC of object properties HT

We partially fixed this in bug #78379, but still don't handle
the case where the properties array is marked as grey first,
which causes a delref to not be performed later.

Fix this by treating the object properties HT the same way as
other refcounted values, including addrefs/delrefs. The object
dtor code already handles properties HT with NULL GC type, so
out of order destruction should not be a problem.

Fixes oss-fuzz #36023.

show more ...

Fix bug #80072: Root live tmpvars after GC

TMPVAR operands are destroyed using zval_ptr_dtor_nogc(), because
they usually cannot contain cycles. However, there are some rare
exceptio

Fix bug #80072: Root live tmpvars after GC

TMPVAR operands are destroyed using zval_ptr_dtor_nogc(), because
they usually cannot contain cycles. However, there are some rare
exceptions where this is possible, e.g. unserialize() return value.
In such cases we rely on the producing code to root the value. If
a GC run occurs between the rooting and consumption of the value,
we would end up leaking it. To avoid this, root all live TMPVAR
values after a GC run.

Closes GH-7210.

show more ...

Convert some recently introduced zend_bool to bool

As well as `scripts/dev/check_parameters.php` utility.

Cfr. 3e01f5afb1b52fe26a956190296de0192eedeec1

Add API to prevent Fiber switch in select contexts

Co-authored-by: Martin Schröder <m.schroeder2007@gmail.com>

Rerun GC if destructors encountered

Since PHP 7.4 objects that have a destructor require two GC runs
to be collected. Currently the collection is delayed to the next
automatic GC run

Rerun GC if destructors encountered

Since PHP 7.4 objects that have a destructor require two GC runs
to be collected. Currently the collection is delayed to the next
automatic GC run. However, in some cases this may result in a large
increase in memory usage, as in one of the cases of bug #79519.

See also bug #78933 and bug #81117 where the current behavior is
unexpected for users.

This patch will automatically rerun GC if destructors were encountered.
I think this should not have much cost, because it is very likely that
objects on which the destructor has been called really are garbage,
so the extra GC run should not be doing wasted work.

Closes GH-5581.

show more ...

Don't perform recursive get_gc call

On further consideration, we should be making use of the fact
that zend_object_iterator is also a zend_object here, and let
GC handle the get_gc c

Don't perform recursive get_gc call

On further consideration, we should be making use of the fact
that zend_object_iterator is also a zend_object here, and let
GC handle the get_gc call on it. Calling get_gc recursively like
this is generally not safe, because there is only one gc_buffer.

This also happens to be much simpler...

show more ...