A way to stop GC wasting CPU time on long-lived objects (GC generations or something else)

Description

PHP's GC is currently unsuited to long-running applications because of the lack of GC generations.

Any application which has long-lived objects with many descendents (such as PocketMine-MP's Server) will currently experience significant performance hits from GC runs due to the expense of repeatedly scanning complex dependencies of these objects.

I haven't dived deep into this problem, but I did verify that just the Server alone winding up in the GC root buffer in PocketMine-MP (which it should never do, being an object that stays alive for almost the entire process) costs 1.7 ms of GC time on a 12700k. An average GC run in PM during normal operation costs somewhere in the ballpark of 15ms, despite creating almost zero cycles.

This is a massive performance impact to PM on account of its update cycle taking place every 50 ms, so a 15ms GC pause is serious business.

Runtimes like .NET and Java have GC generations to avoid this problem, which avoid frequently scanning complex long-lived objects.

I understand that the benefit to PHP is relatively small, given that the primary use case is to serve short-lived web requests, but implementing generations in GC would positively affect performance of long-lived applications.

Beginne mit dem verlinkten PocketMine-MP src/Server.php-Beispiel, um den langlebigen Objektgraphen und die gemeldeten GC-Kosten zu verstehen. Suche anschließend die GC-Implementierung von PHP und die relevanten Tests, reproduziere das hier beschriebene wiederholte Scannen und definiere als abgeschlossen einen getesteten Ansatz, der den Aufwand für langlebige Objekte reduziert und gleichzeitig die Zyklussammlung erhält.