Support for preloading on Windows was removed in [1] [2]:
On Windows, the preloading functionality is fairly crippled, because classes that reference internal classes or constants in some way cannot be preloaded due to ASLR restrictions. As this is a very significant restriction, it will not be possible to preload any non-trivial codebase on Windows.
This is because on Windows the opcache SHM may be reattached from different processes, whose address layout is different, due to ASLR. Therefore SHM can't reference non-SHM addresses on Windows.
One solution is to drop support for reattachment, as suggested in [3]. Reattachment is only needed by process-based SAPIs: FastCGI. The Apache2 SAPI uses reattachment as well, but merging [4] would fix that. [5] would ensure that we have at least 2 Windows SAPIs that don't need reattachment. The FastCGI SAPI would consume more memory on Windows. CLI tools running multiple PHP processes, with opcache enabled, would also consume more memory.
I've also suggested this in [4][7], but this didn't get traction.
But, what seems to have passed under the radars is that since 7.4 we don't reattach at all when ASLR is enabled (or at least when the address layout changed) [6]. Therefore any of the ASLR-related limitations no longer have a reason to exist, as we never have reattachment and ASLR at the same time.
Therefore we could bring back preloading on Windows. This is what this PR does.
Alternatively we could bring back reattachment on ASLR by fixing the invariant "SHM can not reference non-SHM addresses". We can achieve this by adding indirections in places that reference non-SHM addresses, such as in zend_op.handler. As this invariant has not been tested for 6 years, we may discover that other places need to be fixed. We could bring back preloading on Windows if we added these indirections on zend_class_entry.parent and other references to internal definitions. However this adds complexity and slows down the VM.
Bringing back preloading on Windows would facilitate [8]. The "SHM can not reference non-SHM addresses" invariant blocks it.
Any thoughts?
(Windows test failure unrelated.)
Uh oh!
There was an error while loading. Please reload this page.
Support for preloading on Windows was removed in [1] [2]:
This is because on Windows the opcache SHM may be reattached from different processes, whose address layout is different, due to ASLR. Therefore SHM can't reference non-SHM addresses on Windows.
One solution is to drop support for reattachment, as suggested in [3]. Reattachment is only needed by process-based SAPIs: FastCGI. The Apache2 SAPI uses reattachment as well, but merging [4] would fix that. [5] would ensure that we have at least 2 Windows SAPIs that don't need reattachment. The FastCGI SAPI would consume more memory on Windows. CLI tools running multiple PHP processes, with opcache enabled, would also consume more memory.
I've also suggested this in [4][7], but this didn't get traction.
But, what seems to have passed under the radars is that since 7.4 we don't reattach at all when ASLR is enabled (or at least when the address layout changed) [6]. Therefore any of the ASLR-related limitations no longer have a reason to exist, as we never have reattachment and ASLR at the same time.
Therefore we could bring back preloading on Windows. This is what this PR does.
Alternatively we could bring back reattachment on ASLR by fixing the invariant "SHM can not reference non-SHM addresses". We can achieve this by adding indirections in places that reference non-SHM addresses, such as in
zend_op.handler. As this invariant has not been tested for 6 years, we may discover that other places need to be fixed. We could bring back preloading on Windows if we added these indirections onzend_class_entry.parentand other references to internal definitions. However this adds complexity and slows down the VM.Bringing back preloading on Windows would facilitate [8]. The "SHM can not reference non-SHM addresses" invariant blocks it.
Any thoughts?
(Windows test failure unrelated.)