Add a WeakReference memory cache implementation

Note: the memory issues in #2558857: Migrations invalidate entity caches when trying to reclaim memory, should flush are not 100% resolved with clearing entity cache. Drush and Drupal slowly seem to eat up and not release more memory over time with migrations. But once we land that issue, it will be much easier to see any other places for improvement. Baby steps.

Updated the test content

1. +++ b/core/tests/Drupal/Tests/Core/Cache/WeakReferenceMemoryCacheTest.php
   @@ -0,0 +1,37 @@
   + * @coversDefaultClass \Drupal\Core\Cache\MemoryCache\LruMemoryCache
   

   Wrong class name

2. +++ b/core/tests/Drupal/Tests/Core/Cache/WeakReferenceMemoryCacheTest.php
   @@ -0,0 +1,37 @@
   +class WeakReferenceMemoryCacheTest extends UnitTestCase {
   

   Shouldn't this extend \Drupal\system\Tests\Cache\GenericCacheBackendUnitTestBase? (And be a kernel test)

Addressed #11

Here I have tried to address comment #13.

Here's a more functional version of the test that implements the required abstract method.

The base test catches one bug that I fixed. The current patch assumes the data to be an object but its mixed so only passing objects to weak reference seems to be the answer.

There are still some failures that I didn't really look too closely at yet. It looks like maybe the generic test is asserting some PHP pass by value or return by value behaviors that might be a bit different for weak references.

Tried to fix custom command failures. Please review.

I spent a good amount of time tonight reviewing this manually and also running the new test methods locally. Only nit I have from a DX standpoint here is that the test would be more helpful, perhaps, to people new to the WeakReference concept if the docblock on ::testSetGetNoReference() explained more about why the test is skipped; that is, the object in the cache *will* change if you alter its properties after retrieving it.

Might be a stupid question, but is it possible that someone might be relying on the existing behaviour, which guards against this via serialization? Does this need a change record to note that this is truly a reference to an object in a static cache, vs. a repository that stores the object as it was when set?

This will be great to have in Drupal core! I for sure ran into problems related to this while working on migrations!

I guess given #26 we're back to LRU as often an entity will not remain in scope so the entity memory cache wouldn't really be helped by this at all.

I posted https://bugs.php.net/bug.php?id=80951 - let's see if that get's any traction.

I posted https://bugs.php.net/bug.php?id=80951 - let's see if that get's any traction.

Fixed Custom Commands Failed.

> This makes [weakrefs] pretty useless for our purposes.

Interesting problem. What if we use refcycle black magick to save the weakref from the refcounter. PHP has a hardcoded limit of 10k refcycles before auto-gc, so doing that for cache items is pretty useless, but if we weakref the cache service itself, the limit should be OK for now. "10k cache services are enough for everyone".

Here's a Proof Of Concept that and how #34 can be done:
https://3v4l.org/MG8tb

Hm, geek-merlin's idea is certainly cool. Although I came to wonder why we are relying on PHP's garbage collection anyway. With its hardcoded 10k value it seems somewhat arbitrary anyway when things get purged.

We could also have 2 different bins. In one bin go normal/non-weak/"strong" references in the other bin go the weak references. At first if I set sth., it goes to the strong bin together with a value. It could be a timestamp or it could even be the number of garbage cycles (gc_status) to emulate PHP's garbage collection behavior. And then if sth. new goes in, we always compare whether some stuff in the strong bin should go to the weak bin (if some time has passed, some garbage cycles took place, whatever). This way, the conditions WHEN that actually happens could be a bit more predictable and configurable...

Just thinking out loud - ignore me if it sounds too crazy ;-)

I tested #33 on a batched post update hook that was running out of memory loading ~1500 nodes in batches of 50. Before the patch memory usage was increasing a few MB with every batch, after the patch the memory usage remains pretty much constant. The patch no longer applies to 9.2.x or 9.3.x.

Rerolled the patch in #33 as requested in #38, thanks!

@mstrelan: thanks for the super valuable real-world testing!

I should add that the update was executed via drush in case that makes a difference.

As 8.0 a minimum for core 10 I bet it safe to make it real

We were running into memory issues on our hosted environments (the dreaded The process has been signaled with signal "9". error) when migrating 3.5k entities (for some reason locally drush would correctly create a new thread).

With patch #39 we no longer had new threads created locally and the upgrade ran flawlessly on our hosted environment!

Or, it was effectively acting as a null cache backend, which solved the memory problem as it wasn't actually caching anything?

-_- damn

Meantime Symfony reverted weak references for DI because of https://github.com/symfony/symfony/issues/50439