Remember when large arrays don't contain any collectable elements, and avoid wasting GC time on them

[dktapps]

Description

Large arrays pay a very large and frequent GC penalty in long-lived applications.
It should be possible to significantly reduce this impact by introducing a flag like GC_MAY_HAVE_COLLECTABLE_ELEMENTS for arrays, and not scanning the array if no such elements are present.

In the following test case, GC runs take several hundred ms with these arrays containing only primitives. If $test is repeatedly ref'd and unref'd, as is the case for long-lived objects in some applications, these huge arrays will repeatedly get scanned for GC-able elements, wasting CPU time.

Of particular interest is the fact that the readonly array is obviously not modifiable, so it can't possibly contain any GC-able elements if it didn't have any the first time it was scanned. Yet if you modify the test case you can easily tell from the length of time the GC spends that it does still repeatedly scan this array.

class Test{
	public function __construct(
		private readonly array $readonlyArray,
		public array $writableArray = []
	){}
}

ini_set('memory_limit', '-1');
$test = new Test(array_fill(0, 50_000_000, 0), array_fill(0, 50_000_000, 0));
$ref2 = new \stdClass();
$ref2->test = $test; //increase refcount
unset($test); //decrease refcount, object is now in gc root buffer
$start = hrtime(true);
gc_collect_cycles();
var_dump(number_format(hrtime(true) - $start));

$test = $ref2->test; //increase refcount
unset($ref2->test); //decrease refcount
$start = hrtime(true);
gc_collect_cycles();
var_dump(number_format(hrtime(true) - $start));

[iluuu1994]

This is very much related to #17131.

It should be possible to significantly reduce this impact by introducing a flag like GC_MAY_HAVE_COLLECTABLE_ELEMENTS for arrays, and not scanning the array if no such elements are present.

I already tried something like this (#9979), but it wasn't profitable. I later also realized that it isn't sound when nested arrays and references are involved.

We could try a slightly simpler approach by flagging the array as uncollectable when scanning it in the GC if it only contained primitive elements, and unflagging on any modification. This should be a more localized change and wouldn't require touching the VM. That said, I'm still skeptical this makes a meaningful difference, and the additional checks may offset any benefit.

Of particular interest is the fact that the readonly array is obviously not modifiable, so it can't possibly contain any GC-able elements if it didn't have any the first time it was scanned.

This assumption is incorrect. readonly is a property trait, not an array trait, meaning we don't now whether an array is stored in a readonly property. Moreover, if the element can be part of a cycle, and is released last, it is by definition the root of the cycle even if it was previously checked and has not been modified since. Meaning, it's safe to make this assumption iff the array contains only non-cyclic elements (everything but arrays|objects|references).

[dktapps]

We could try a slightly simpler approach by flagging the array as uncollectable when scanning it in the GC if it only contained primitive elements, and unflagging on any modification. This should be a more localized change and wouldn't require touching the VM. That said, I'm still skeptical this makes a meaningful difference, and the additional checks may offset any benefit.

Yeah, this is basically what I was going for.

It depends on the array size, but there's a bunch of operations that have to take place on array write anyway, so it shouldn't be a concern, no? It'd just be one extra instruction, and the benefits of skipping arrays with thousands of elements are, in my experience, pretty substantial (I verified using an extension in my application).

[iluuu1994]

but there's a bunch of operations that have to take place on array write anyway, so it shouldn't be a concern, no?

Sure, but: Many, if not most, pages don't trigger the GC. It's much more common to be triggered for CLI applications, which is not PHPs primary target. And given array operations are incredibly common, this may still add up to a sizeable amount. I created a PoC here (#19626), so feel free to test how it impacts performance in your application. It works for the reproducer you provided at least.

[dktapps]

Many, if not most, pages don't trigger the GC. It's much more common to be triggered for CLI applications, which is not PHPs primary target.

Fair. I hadn't given much thought to this since I mainly work with PHP CLI.

I suppose the ideal situation would be if this optimisation were able to be done for specific SAPIs to avoid a performance hit. Not sure if that's possible with current PHP architecture.

[dktapps]

I suppose this also makes an unexpected case for typed arrays if that happens to be on anyone's radar :)

[iluuu1994]

I suppose the ideal situation would be if this optimisation were able to be done for specific SAPIs to avoid a performance hit. Not sure if that's possible with current PHP architecture.

Not trivially, with the current build process. Object files are shared for all SAPIs.