One more; I made this quick&dirty solution that is clearing memory via Reflection:

    public function onKernelTerminate()
    {
        $choiceLoadersReflection = $this->getReflection();
        $choiceLoadersReflection->setValue($this->entityType, []);
    }

    private function getReflection()
    {
        if (!$this->reflection) {
            $reflection = new \ReflectionObject($this->entityType);
            $doctrineType = $reflection->getParentClass();
            $loaders = $doctrineType->getProperty('choiceLoaders');
            $loaders->setAccessible(true);
            $this->reflection = $loaders;
        }

        return $this->reflection;
    }

I am aware it is bad but it works.

If I'm understanding this issue correctly:
Considering you're using a setup where the objects are shared between users because it uses the same instance, that seems to be intended behavior and not necessarily a memory leak.

You can probably solve this by not binding your entity to a form directly, but using a DTO: https://stovepipe.systems/post/avoiding-entities-in-forms

@iltar You are right, I was thinking about using DTO but I find that solution as too complex (no offence). For example, if I have a form with collection and that collection has its own collection, extra code needed would go beserk.

Example of such form is editing album with tagged users. Check this:

S3 form system would automatically call adders and removers. So at least for now, I would prefer using entities directly. With $em->clear() in kernel.terminate, I don't need to use DTO.

that seems to be intended behavior and not necessarily a memory leak

EntityType::class keeps all those objects in choiceLoaders property. Because it is shared, it can quickly fill up the memory which makes it memory leak.

My solution with ReflectionObject is bad. mostly because it prevents decorating it via MyEntityTypes extend EntityType but I will use it for now.

@iltar On topic of DTO, I did try it to avoid this issue. To avoid extra code, I did something like this:

class MovieDTO extends Movie 
{ 
    // no code here 
}

Extra service copied values from Movie to MovieDTO by reading form fields. It sortof worked, can't remember what the problem was but I am thinking of extending FormType with key dto_class and service decorator that make data copying between these two.

English is not my first language so I hope the above makes sense, 😄

Well, the way phppm works means that any kind of memoization turns into long-term memory leaks, because it got rid of the fact that the PHP process lives only until the end of the request processing. Your proposal would require that any library doing memoization would implement the same interface (and so depend on the package containing it as it is not part of PHP) to be compatible with phppm (to allow to build such a listener calling their clean method). I don't think making this interface part of Symfony itself will work (external libraries doing memoization will not want to depend on Symfony for that), and I'm not even sure they would be willing to make such change to accommodate a need specific to phppm.

I don't think making this interface part of Symfony itself will work

I was thinking of something like I made for this problem (bundle here):

class MemoryCleaner implements EventSubscriberInterface
{
    /**
     * @var MemoryCleanerInterface[]
     */
    private $cleaners;

    /**
     * $cleaners set in @see MemoryCleanerPass
     *
     * @param MemoryCleanerInterface[] $cleaners
     */
    public function __construct(array $cleaners = [])
    {
        $this->cleaners = $cleaners;
    }

    public static function getSubscribedEvents()
    {
        return [
            'kernel.terminate' => 'onKernelTerminate',
        ];
    }

    public function onKernelTerminate()
    {
        foreach ($this->cleaners as $cleaner) {
            $cleaner->clean();
        }
    }
}

and this pass:

class MemoryCleanerPass implements CompilerPassInterface
{
    public function process(ContainerBuilder $builder)
    {
        if (!$builder->hasDefinition(MemoryCleaner::class)) {
            return;
        }
        $definition = $builder->getDefinition(MemoryCleaner::class);
        $taggedCleaners = $builder->findTaggedServiceIds(MemoryCleanerInterface::class);
        $cleaners = [];
        foreach ($taggedCleaners as $id => $tags) {
            $cleaners[] = new Reference($id);
        }
        $definition->setArgument(0, $cleaners);
    }
}

and this line in Extension::load()

$builder->registerForAutoconfiguration(MemoryCleanerInterface::class)->addTag(MemoryCleanerInterface::class);

So it is totally optional, if someone wants to clean memory, he only needs to implement the interface. If it goes into standard Symfony distro, I think people would quickly adopt it because phppm is just too good.

Closed in favor of #23984