Anonymous class names change based on the opcache status of the PHP file

[nunomaduro]

Description

It seems that anonymous class names change based on the opcache status of the PHP file that includes the anonymous class declaration. Here is an example:

<?php // A.php

var_dump(get_class(require 'B.php'));
var_dump(get_class(require 'B.php'));
var_dump(get_class(require 'B.php'));
var_dump(get_class(require 'B.php'));

<?php // B.php

return new class {};

Resulted in this output:

# First Scenario "Without opcache":
➜ php -d "opcache.enable_cli"=0 A.php
/Users/nunomaduro/demo/A.php:3:
string(48) "class@anonymous\000/Users/nunomaduro/demo/B.php:3$5"
/Users/nunomaduro/demo/A.php:4:
string(48) "class@anonymous\000/Users/nunomaduro/demo/B.php:3$6"
/Users/nunomaduro/demo/A.php:5:
string(48) "class@anonymous\000/Users/nunomaduro/demo/B.php:3$7"
/Users/nunomaduro/demo/A.php:6:
string(48) "class@anonymous\000/Users/nunomaduro/demo/B.php:3$8"

# Second Scenario "With opcache" (and after running the script once, so the file gets cached)
➜ php -d "opcache.enable_cli"=1 A.php
/Users/nunomaduro/demo/A.php:3:
string(48) "class@anonymous\000/Users/nunomaduro/demo/B.php:3$5"
/Users/nunomaduro/demo/A.php:4:
string(48) "class@anonymous\000/Users/nunomaduro/demo/B.php:3$5"
/Users/nunomaduro/demo/A.php:5:
string(48) "class@anonymous\000/Users/nunomaduro/demo/B.php:3$5"
/Users/nunomaduro/demo/A.php:6:
string(48) "class@anonymous\000/Users/nunomaduro/demo/B.php:3$5"

It's unclear to me whether the "expected" output should correspond to the first or the second scenario. However, the fact that the generated class names vary depending on the opcache status of the file is what prompted me to create the issue.

PHP Version

PHP 8.2.8, PHP 8.1.22, etc.

Operating System

No response

[ju1ius]

Also:

<?php // A.php

$a = require 'B.php';
$b = require 'B.php';
var_dump($a instanceof $b);

<?php // B.php

return new class {};

➜ php -dopcache.enable_cli=0 A.php
bool(false)

➜ php -dopcache.enable_cli=1 A.php
bool(true)

[mvorisek]

Some time ago I coded a test for it - #7563 - as long as the class in the included file did not change, the class should be the same, one reason for it is memory will increase otherwise, as no class (the previously loaded one) cannot be unregistered.

[KapitanOczywisty]

as long as the class in the included file did not change, the class should be the same

If you put normal class in B file you will get redefinition error, the same way anonymous class should be the new one. And this is exactly because you could edit B file content between consecutive includes and PHP wouldn't have any (efficient) way to check that definition not changed.

Class definition and name is created when file is parsed, class instance is created when PHP executes line of code. If code is parsed multiple time, there should be multiple definitions. Opcache keeps generated name around and this is a bug.

[ju1ius]

I understand the memory considerations but IMO opcache should not change the observable side-effects of the require call in this case.

I mean, if we change OP's example to return mt_rand();, you expect it to return a different value each time the file is required, whether or not opcache is enabled. Similarly, return new class {}; should always return a new instance of a new class definition.

[iluuu1994]

Differences between vanilla PHP and opcache are inevitable. I don't think there's a good reason to try to match the behavior when the name of an anonymous class is essentially meaningless. Redeclaring the class for every inclusion of the file will negatively impact performance.

Similarly, return new class {}; should always return a new instance of a new class definition.

A different class per instance is not viable. Each class lives until the end of the request. That would fill your memory very quickly when creating temporary anonymous class instances.

[ju1ius]

A different class per instance is not viable. Each class lives until the end of the request.

I know that very well. However I don't think this is the issue here.

The issue is that using opcache effectively changes the observable behaviour of the program, which is a no-no for any kind of compiler.

In the OP's example, he is explicitely asking for a new instance of a new class defintion twice. The program behaves correctly without opcache and incorrectly with opcache.

If an internal mechanism is used to reduce memory usage, it should not be externally observable (in OP's case$a instanceof $b should always return false). Whether that's feasible in practice is another issue and IMO doesn't change the fact that this behaviour is indeed a bug.

[iluuu1994]

In an idealized world we could make opcache behaviorally equivalent without loosing any potential for optimization or increasing implementation complexity. However, that's not the case, so we have to find a compromise. Is there any actual use for observing the name of an anonymous class or is it just something that was noticed? If there is a good use case we can consider finding a solution. I don't think any discrepancy should be addressed if it has no relevance in real applications.

Also note that there are other known discrepancies between opcache and non-opcache, like early binding, constant evaluation, etc. There are others, but I can't think of them off the top of my head.

[ju1ius]

Is there any actual use for observing the name of an anonymous class or is it just something that was noticed?

None that I can think of, but this also affects instanceof checks, and one may envision an actual use for instanceof.

But at that point, @nunomaduro should indeed tell a bit more about his actual use case. 😉

[github-actions]

No feedback was provided. The issue is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so. Thank you.