I tested some more and found out, that this bug occures infrequently, and the chances of occurence are higher, if the invalidated script is used/included multiple times (included in a web application, for example) before it is invalidated again, at least that is my theory. If the PHP file is cached once and never used, opcache_invalidate does not increase wasted memory, at least I cannot reproduce it that way.

Yet opcache_invalidate and the use of opcache do not have to be simultaneous. The most "regular" results of an increase in wasted memory were with a website where a PHP file is included in every page with multiple views per minute, and a cron job once a minute where some scripts are invalidated. I also have a feeling that larger scripts increase the chances, but I am not sure.

One PHP file which is included and produces this error quite regularly can be found on http://www.panaxis.ch/categories.php - to reproduce I would recommend to load a website which includes that PHP file every 10 seconds, and invalidate the file with opcache_invalidate every minute. With about that setup I reached 350MB of wasted space in 3 hours, quite consistently.

Sorry for the imprecise description - I tried to find some method to make it 100% reproduceable, but did not find a clear way. I hope somebody with inside knowledge of opcache reads this and got enough information to know what causes this, or to know what to look for.

Sorry, link was wrong, here is the correct link for categories.php: https://www.purplestar.com/categories.php

This is like OPcache is supposed to behave: for performance
reasons, invalidated files are never freed (there is no
defragmentation)[1], and as such reported as wasted memory.

[1] <http://blog.jpauli.tech/2015-03-05-opcache-html/>