Compile in opcache without COMPILE_IGNORE_INTERNAL_CLASSES

[iluuu1994]

I don't believe there's a reason to compile with this flag. We don't rely on fixed addresses anyway, relying on the signatures of the symbols themselves should be fine.

The same goes for file cache itself, as we don't allow loading cache files across PHP versions.

Waiting for Dmitry to verify, once he's back from vacation.

[arnaud-lb]

Should we check for temporary internal classes? (loaded by dl())?

BTW I believe that this comment is outdated:

php-src/Zend/zend_compile.h

Lines 1218 to 1221 in 6857c7c

	/* don't perform early binding for classes inherited form internal ones;
	* in namespaces assume that internal class that doesn't exist at compile-time
	* may appear in run-time */
	#define ZEND_COMPILE_IGNORE_INTERNAL_CLASSES (1<<4)

Last time I checked, I think that this flag was added after initial namespace support landed, but before the current namespace resolution rules was implemented.

[iluuu1994]

Should we check for temporary internal classes? (loaded by dl())?

Don't dl()ed classes persist until the end of the request, given that they can only be loaded in CLI?

BTW I believe that this comment is outdated:

I don't know about this comment, but I think persisting classes linked to internal ones would be unsafe for Windows, where shm can be attached to different processes, with internal symbols having different addresses.

Edit: Anyway, this is not even about linking at compile time, so.

[arnaud-lb]

Should we check for temporary internal classes? (loaded by dl())?

Don't dl()ed classes persist until the end of the request, given that they can only be loaded in CLI?

Right, forgot that dl() is only enabled in CLI.

[iluuu1994]

I think we actually need to add a check on Windows to prevent early-binding:

php-src/Zend/zend_compile.c

Line 9067 in 6857c7c

&& !zend_compile_ignore_class(parent_ce, ce->info.user.filename)) {

Because it also relies on the ZEND_COMPILE_IGNORE_INTERNAL_CLASSES flag being set. Or, we just set ZEND_COMPILE_IGNORE_INTERNAL_CLASSES for Windows.

[dstogov]

file cache may be used after php.ini change that removes some shared extensions.
So some internal classes may disappear.

[iluuu1994]

file cache may be used after php.ini change that removes some shared extensions.

That's true. So, I suppose we need to set this flag for both file cache and Windows then.

[dstogov]

That's true. So, I suppose we need to set this flag for both file cache and Windows then.

because of ASLR? or because different workers may have different sets of shared extensions?
Can you please check how this works on Windows now? Do we store references to internal class in SHM?

[iluuu1994]

because of ASLR?

Yes.

or because different workers may have different sets of shared extensions?

Honestly, I have no idea how this works on Windows. I've never developed php-src on Windows.

Can you please check how this works on Windows now? Do we store references to internal class in SHM?

Before this PR, we only store references to internal classes on non-Windows with inheritance cache. Windows is explicitly disabled.

php-src/Zend/zend_inheritance.c

Lines 3339 to 3342 in 82479e8

	// TODO: ASLR may cause different addresses in different workers ???
	# define UPDATE_IS_CACHEABLE(ce) do { \
	is_cacheable &= (ce)->ce_flags; \
	} while (0)

Since we're already support persisting classes linked with internal classes, we may as well compile with them. For Windows, we should continue not to persist classes linked with internal classes for both internal cache and regular cache.

[dstogov]

Can this cause a BC break if the child class is defined in namespace and we have a parent class with the same name as an internal one in the same namespace but different file?

[iluuu1994]

Can this cause a BC break if the child class is defined in namespace and we have a parent class with the same name as an internal one in the same namespace but different file?

No, as classes don't have a fallback to the global namespace.