opcache.interned_strings_buffer either has no effect or opcache_get_status() / phpinfo() is wrong

[gndk]

Description

In my php.ini I have set opcache.interned_strings_buffer to 16.

phpinfo() confirms this:

But opcache_get_status()...

and phpinfo()...

... show interned_strings_usage['buffer_size'] as full at ~6mb.

I don't know if it's relevant, but opcache has enough free memory:

But the used_memory and free_memory also add up to a different value than the 1024 I set for opcache.memory_consumption, although close.

PHP Version

8.2.8

Operating System

Ubuntu 20.04

[ndossche]

I just tried this and got a different, but equally weird result.
I got 193752 used, 12388696 free. Sum that up and you get 12582448, which is just under 12MiB, less than the 16 I set it at 🤔

EDIT: I don't understand this code:

php-src/ext/opcache/ZendAccelerator.c

Lines 2904 to 2906 in cbd903d

	ZCSG(interned_strings).end =
	(zend_string*)((char*)accel_shared_globals +
	ZCG(accel_directives).interned_strings_buffer * 1024 * 1024);

I would've expected this instead:

		ZCSG(interned_strings).end =
			(zend_string*)((char*)ZCSG(interned_strings).start +
				ZCG(accel_directives).interned_strings_buffer * 1024 * 1024);

i.e. to compute the end, instead of starting from the start of the struct, we start at the interned string table start. This makes more sense to me. And this yields the right result on my computer. But I'm not sure, I didn't look too deep into it yet as I'm out of time for today.

EDIT 2: Wait but then this line is also wrong:

php-src/ext/opcache/ZendAccelerator.c

Line 2864 in cbd903d

accel_shared_globals_size = ZCG(accel_directives).interned_strings_buffer * 1024 * 1024;

I'm confused

[gndk]

Glad you could confirm!

I'm confused

Well, sorry to add to the confusion, but I actually had it set to 256 before (which I then realised was much too high), but even with that it still was stuck on the 6mb from my screenshot..

[ndossche]

I think I figured it out and will try to create a PR soon.
There's two issues I think: the end calculation is wrong, and the memory usage/free reporting is using the wrong values.
I think if I'm right, it makes sense you're seeing that 6MB behaviour.