Add new core autoloading mechanism for classes and functions by Girgias · Pull Request #8294 · php/php-src

Girgias · 2022-04-01T22:12:56Z

This PR introduces a new autoloading mechanism built into the engine which supports the autoloading of classes and functions.

RFC: https://wiki.php.net/rfc/core-autoloading

Danack · 2022-10-06T13:14:15Z

fyi, the test Zend/tests/autoloading/function/register_autoloader.phpt appears to be failing due to the param parsing failing as the passed in string is not already callable.

Zend/zend_autoload.c

Danack · 2022-10-06T13:27:34Z

The test exceptions_during_autoloading004.phpt appears to be failing as the function autoloading doesn't appear to be triggered for the function in a namespace.

…ot be unregistered) There are two issues to resolve: 1. The FCC is not refetch when trying to unregister a trampoline 2. Comparing the function pointer of trampolines is meaningless as they are reallocated, thus we need to compare the name of the function Found while working on phpGH-8294

…be unregistered) There are two issues to resolve: 1. The FCC is not refetch when trying to unregister a trampoline 2. Comparing the function pointer of trampolines is meaningless as they are reallocated, thus we need to compare the name of the function Found while working on GH-8294 Closes GH-10033

dstogov · 2023-04-17T09:23:23Z

Zend/zend_vm_def.h

-		function_name = (zval*)RT_CONSTANT(opline, opline->op2);
-		func = zend_hash_find_known_hash(EG(function_table), Z_STR_P(function_name+1));
-		if (UNEXPECTED(func == NULL)) {
-			ZEND_VM_DISPATCH_TO_HELPER(zend_undefined_function_helper);
+		zval *function_name = (zval*)RT_CONSTANT(opline, opline->op2);
+		/* Fetch lowercase name stored in the next literal slot */
+		fbc = zend_lookup_function_ex(Z_STR_P(function_name), Z_STR_P(function_name+1), /* use_autoload */ true);
+		if (UNEXPECTED(fbc == NULL)) {
+			if (EXPECTED(!EG(exception))) {
+				ZEND_VM_DISPATCH_TO_HELPER(zend_undefined_function_helper);
+			}
+			HANDLE_EXCEPTION();


I would propose to try autoloading only after simple hash lookup.
This should completely eliminate performance degradation for existing code.
e.g.

function_name = (zval*)RT_CONSTANT(opline, opline->op2); func = zend_hash_find_known_hash(EG(function_table), Z_STR_P(function_name+1)); if (UNEXPECTED(func == NULL)) { func = zend_autoload_function(Z_STR_P(function_name), Z_STR_P(function_name+1)); if (UNEXPECTED(func == NULL)) { if (EXPECTED(!EG(exception))) { ZEND_VM_DISPATCH_TO_HELPER(zend_undefined_function_helper);

Shouldn't this already be the case because of how I implemented zend_lookup_function_ex()?

As it will first check the HashTable, and then call the autoloader if it hasn't found an entry.

Your implementation introduces overhead of call to zend_lookup_function_ex(), few additional checks and use of zend_hash_find() instead of zend_hash_find_known_hash().

MaxD2 · 2023-07-25T01:29:05Z

I don't know where to write, but I vote for consts (defines) autoloading, that will be extra-usable after const objects got allowed in 8.1.

medabkari · 2024-02-08T14:34:53Z

Is there any plans to implement this feature in 8.4 release?

Girgias · 2024-02-08T22:23:57Z

Is there any plans to implement this feature in 8.4 release?

I need to get back to finishing the RFC to explain why certain proposed ideas don't work. But that's the objective yes.

britkig · 2024-02-16T18:58:54Z

Just a thought, but would it be another logical way of using one, yet-agnostic, list for all autoload functions rather than two, but have a bitflag on each registered callable as to what autoload occasions that function should fire on?

Another possible approach to this is to have a third, but generic, set autoload functions which take a bitwise parameter to map one or more event types (i.e. AUTOLOAD_CLASS=1, AUTOLOAD_FUNCTION=2), and have event-specific functions, as-currently mentioned in the RFC as-of-writing, serve as stubs for one specific autoload type?

Something else to consider, is that there will certainly be cases where a coder may want the exact same segment of code to execute in more than one particular event. From a RAM-occupancy standpoint, having only one copy of a registered function in-memory, where its purpose is to fire on more than one event type, would be a little more efficient. Also, if, in a future RFC, that there is the thought to add more autoload event types, additional bitflags can be reserved for them (i.e. AUTOLOAD_CONSTANT=4), or even have one function to invoke on any autoload event (i.e. AUTOLOAD_ALL=0).

Girgias · 2024-02-17T13:40:43Z

Just a thought, but would it be another logical way of using one, yet-agnostic, list for all autoload functions rather than two, but have a bitflag on each registered callable as to what autoload occasions that function should fire on?

Another possible approach to this is to have a third, but generic, set autoload functions which take a bitwise parameter to map one or more event types (i.e. AUTOLOAD_CLASS=1, AUTOLOAD_FUNCTION=2), and have event-specific functions, as-currently mentioned in the RFC as-of-writing, serve as stubs for one specific autoload type?

Something else to consider, is that there will certainly be cases where a coder may want the exact same segment of code to execute in more than one particular event. From a RAM-occupancy standpoint, having only one copy of a registered function in-memory, where its purpose is to fire on more than one event type, would be a little more efficient. Also, if, in a future RFC, that there is the thought to add more autoload event types, additional bitflags can be reserved for them (i.e. AUTOLOAD_CONSTANT=4), or even have one function to invoke on any autoload event (i.e. AUTOLOAD_ALL=0).

I don't think this is a good API at all. Which is why I did not go with this in the first place, the previous proposal for function autoloading did just that, and I think it is confusing and if one of the autoloading mechanisms needs to be amened to behave differently via a flag or what-no this would pollute the whole API surface.

Individual functions are cheap, and clear.

Moreover, I frankly think it is unlikely that a class autoloader and a function autoloader are remotely close in implementation. Classes in PHP are typically stored in a one to one correspondences with files, whereas doing that for functions is a questionable choice.

Similarly, thing for autoloading constants, or type aliases.

OpCache doesn't work properly as the local function gets bound to a global one.

…all" This approach doesn't really work This reverts commit 060bab7.

Girgias added RFC Feature Category: Engine labels Apr 1, 2022

Danack reviewed Oct 6, 2022

View reviewed changes

Zend/zend_autoload.c Show resolved Hide resolved

Girgias force-pushed the zend_autoloader branch from 62b7697 to 29c9cc9 Compare October 24, 2022 13:56

github-actions bot added the Extension: spl label Oct 24, 2022

Girgias force-pushed the zend_autoloader branch from 29c9cc9 to ee63c9b Compare November 28, 2022 04:04

This was referenced Nov 28, 2022

Trampoline autoloader will get reregistered and cannot be unregistered #10011

Closed

Fix zend_fcc_equals() with trampolines #10012

Merged

Girgias mentioned this pull request Dec 2, 2022

Fix GH-10011 (Trampoline autoloader will get reregistered and cannot … #10033

Closed

Girgias force-pushed the zend_autoloader branch from ee63c9b to 874b3f5 Compare December 6, 2022 02:11

Girgias force-pushed the zend_autoloader branch 2 times, most recently from ca7a80f to 41f9378 Compare December 15, 2022 02:04

Girgias force-pushed the zend_autoloader branch 2 times, most recently from 2e93f3c to f88a32e Compare April 3, 2023 13:02

Girgias mentioned this pull request Apr 3, 2023

Mark filename parameter as const for zend_resolve_path() #11003

Closed

Girgias force-pushed the zend_autoloader branch 3 times, most recently from 359966e to 90c39d3 Compare April 12, 2023 16:31

dstogov reviewed Apr 17, 2023

View reviewed changes

Girgias force-pushed the zend_autoloader branch from 7aaae2e to cc22fb5 Compare May 6, 2023 09:23

github-actions bot added the Category: Optimizer label May 6, 2023

Girgias force-pushed the zend_autoloader branch from cc22fb5 to e6d02e3 Compare May 31, 2023 12:41

Girgias mentioned this pull request Aug 17, 2024

Update ext/spl dependencies #14544

Closed

Girgias added 6 commits August 17, 2024 19:16

Introduce zend_lookup_function()

51493d4

New core class autoloader

c24009c

Implementation of function autoloading

87aec86

Use common function for autoload_list functions

15d6f25

Deprecate BONKERS SPL behaviour

46657a4

Attempt to not alias on autoloading non qualified namespace call

060bab7

OpCache doesn't work properly as the local function gets bound to a global one.

Girgias force-pushed the zend_autoloader branch from e6d02e3 to 060bab7 Compare August 17, 2024 18:04

github-actions bot added the Category: Build System label Aug 17, 2024

Girgias added 2 commits August 18, 2024 00:26

Revert "Attempt to not alias on autoloading non qualified namespace c…

8e72f7b

…all" This approach doesn't really work This reverts commit 060bab7.

JIT Support for function autoloading

18c52c2

github-actions bot added the Extension: opcache label Aug 18, 2024

Fix SPL return type

7b2b59f

Girgias mentioned this pull request Jan 5, 2026

ext/spl: refactor class autoloading to use newer FCC APIs #20841

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add new core autoloading mechanism for classes and functions#8294

Add new core autoloading mechanism for classes and functions#8294
Girgias wants to merge 9 commits intophp:masterfrom
Girgias:zend_autoloader

Girgias commented Apr 1, 2022 •

edited

Loading

Uh oh!

Danack commented Oct 6, 2022

Uh oh!

Uh oh!

Danack commented Oct 6, 2022

Uh oh!

dstogov Apr 17, 2023

Uh oh!

Girgias May 5, 2023

Uh oh!

dstogov May 10, 2023

Uh oh!

MaxD2 commented Jul 25, 2023

Uh oh!

medabkari commented Feb 8, 2024

Uh oh!

Girgias commented Feb 8, 2024

Uh oh!

britkig commented Feb 16, 2024

Uh oh!

Girgias commented Feb 17, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

Conversation

Girgias commented Apr 1, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Danack commented Oct 6, 2022

Uh oh!

Uh oh!

Danack commented Oct 6, 2022

Uh oh!

dstogov Apr 17, 2023

Choose a reason for hiding this comment

Uh oh!

Girgias May 5, 2023

Choose a reason for hiding this comment

Uh oh!

dstogov May 10, 2023

Choose a reason for hiding this comment

Uh oh!

MaxD2 commented Jul 25, 2023

Uh oh!

medabkari commented Feb 8, 2024

Uh oh!

Girgias commented Feb 8, 2024

Uh oh!

britkig commented Feb 16, 2024

Uh oh!

Girgias commented Feb 17, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

Girgias commented Apr 1, 2022 •

edited

Loading