Re: [PHP-DEV] 5.3 compile time still depends on runtime constants (Default value for parameters with a class type hint can only be NULL)
sorry, forgot to reply to all http://bugs.php.net/bug.php?id=46850 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] 5.3 compile time still depends on runtime constants (Default value for parameters with a class type hint can only be NULL)
this is a discussion about Default value for parameters with a class
type hint can only be NULL error
let's focus our eyes on
zend_compile.c function zend_do_receive_arg
void zend_do_receive_arg(zend_uchar op, const znode *var, const znode
*offset, const znode *initialization, znode *class_type, const znode
*varname, zend_uchar pass_by_reference TSRMLS_DC)
{
...
if (op == ZEND_RECV_INIT) {
if (Z_TYPE(initialization-u.constant) == IS_NULL ||
(Z_TYPE(initialization-u.constant) == IS_CONSTANT
!strcasecmp(Z_STRVAL(initialization-u.constant), NULL))) {
cur_arg_info-allow_null = 1;
} else {
zend_error(E_COMPILE_ERROR, Default value for
parameters with a class type hint can only be NULL);
}
}
test.php==
?php
namespace My\NS;
use My\NS;
class A {
public function test(A $obj=null) {
var_dump($obj);
}
}
(the following gdb input/output is still using macro for your reading,
expand the macro if you want to execute)
test case 1
precondition: CG(compiler_options) |= ZEND_COMPILE_NO_CONSTANT_SUBSTITUTION;
break at function zend_do_receive_arg and
(gdb) print Z_TYPE(initialization-u.constant) == IS_NULL
1 (true)
which means it still subst null to IS_NULL
test case 2
precondtion: let's assume ZEND_COMPILE_NO_CONSTANT_SUBSTITUTION is
working for zend_do_receive_arg, simply empty hash table
EG(zend_constants) = an_empty_hash_table before zend_compile_file
break at function zend_do_receive_arg and
(gdb) print Z_TYPE(initialization-u.constant) == IS_NULL
0 (false)
(gdb) print Z_TYPE(initialization-u.constant) == IS_CONSTANT
0 (false)
so what is that?
(gdb) print Z_TYPE(initialization-u.constant)
24
(gdb) print (Z_TYPE(initialization-u.constant)
IS_CONSTANT_TYPE_MASK) == IS_CONSTANT
1 (true)
ok, we get the first bug
(gdb) p !strcasecmp(Z_STRVAL(initialization-u.constant), NULL))
0 (false)
why?
(gdb) p Z_STRVAL(initialization-u.constant)
My\\NS\\null
this is the reason. looks likestrcasecmp is not enough here at compile
time. or you could just handle abc(array $a = null) as a special case?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC doesn't work on Windows?
you're right, but too bad there's no PHP_FCGI_CHILDREN (pre-fork) for
windows, not even any alternatives
{{{
#ifndef PHP_WIN32
/* Pre-fork, if required */
if (getenv(PHP_FCGI_CHILDREN)) {
children = atoi(getenv(PHP_FCGI_CHILDREN));
}}}
No, why should it? The cache is shared perfectly fine if you let PHP handle
the process spawning (i.e. increasing PHP_FCGI_CHILDREN instead of running
php-cgi -b (or whatever) multiple times).
I used APC w/ FastCGI some time ago and I'm still using another opcode cache
with FastCGI at the moment (XCache), and I know lots of people doing the
same. :)
--
Christian Hoffmann
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Patch for opcode caches
XCache PHP_5_3 compatibility changeset is commited
http://xcache.lighttpd.net/changeset/548
{{{
$ svn co svn://svn.lighttpd.net/xcache/trunk
}}}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch for opcode caches
session (or caused by TSRM/ZendEngine) seems broken in my local cvs checkout i'm not sure if it's relatived to this patch but i did 'cvs up' and some commit broke the patch (with conflicts) please commit, or roll out another diff against the PHP_5_3 cvs so i can test it again thanks -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch for opcode caches
On Mon, Mar 10, 2008 at 5:59 AM, Marcus Boerger [EMAIL PROTECTED] wrote: Hello Dmitry, please don't apply. The patch looks rather rough and untested (see below). Also I really disagree to making the engine even more complex and adding even more different behavior ways. That way we just introduce more errors as we cannot test the engine in all its modes. We simply do not have the infrastructure for that. And that means we will add even more bugs. Further more I am missgin a description what you really do here and why we need to do that. Ok Opcode caches have issues but so far all attempts to do somethign about that have been blocked. Now this one apparently has a new option. But as far as I can tell it simply allows to change the compiler to an opcode friendly order. If that is all what it does than we should simply drop all the options and do it anyway without flags. just a summary of the patch for those who don't have time to read it: ZEND_COMPILE_EXTENDED_INFO is a new way for the extended_info = 1, no logic changed except the api, only a few modules is affected, and yes it can be changed back to avoid breaking 3rd modules at source level the issues relatived to ZEND_COMPILE_DELAYED_BINDING / ZEND_COMPILE_IGNORE_INTERNAL_* can be fixed without those flags. but when we have the flag off the old implementation is used which is more optimized than the new opcode/encoder friendly implementation. correct me if i'm wrong. i'll leave the discussion to you guys, just move it fast before it's too late. thanks -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch for opcode caches
checked and it works, all test cases that pass without XCache now pass with XCache too. i'll commit after your commit in ZendEngine thanks -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.3 Release Planning
i just hope the issue described in http://www.mail-archive.com/internals@lists.php.net/msg32601.html will be resolved before 5.3 is out. it is the only problem that breaks opcode cacher support as far as i can see by now. e.g.: with this problem fixed, all test cases will pass when XCache is enabled but not without fixed -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.3 Release Planning
gotcha, i'll check it within 24hours thanks for your great work -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] early class binding revisited
any news on this topic? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] early class binding revisited
=
original problem
=
the biggest problem caused by early class binding is that it's
unfriendly to opcode cachers.
parent1.php
class P
{
function __construct()
{
echo parent2;
}
}
include child.php
==
parent2.php
class P
{
function __construct()
{
echo parent2;
}
}
include child.php
==
child.php
class child extends P
{
}
new child();
without opcode cacher, when parent1.php is requested, parent1 is
echoed, while parent2.php is requested parent2 will be echoed.
but with opcode cachers, it always use the echo from first
requested/cached class P because when class child is being cached,
it's after early class binding and is binded with its parent class
P, the binding will not be done again after the child class is
restored from cache
=
other problems
=
read the sample coe first:
class MyException extends Exception
{
}
early class binding is done at compile time and opcode cachers will
only get binded not raw classes
the problem is that, the binded class MyException is has so many
handler pointers copied (inherited) from internal class Exception.
it's hard for a opcode cacher to cache such opcode data to disk, or
share with another instance of php which is not forked from the same
parent php process due to possible symbol relocation.
=
compatibility issue without early class binding
=
iirc the early class binding was removed but added back later due to
back compatibility issue:
if the class is early binded, code before class declaration can use class
new Foo(); // works
class Foo // early binding at compile time
{
}
but when there's no early binding
new Foo(); // error, undefined class
class Foo
{
}
// late class binding is done here at runtime
=
solution proposal
=
solution a: forget the back compatibility issue, early class binding
was deprecated and it's now gone.
solution b: add an api that allow extension/zend_extension disable
early class binding let opcode cachers decide to do nothing (which
mean the user should accept that, the early binding is gone), or to
redo the binding after restore from cache but before execution. when
no extension use this api, no behavior change.
pitfall for solution b: opcode cachers have to write their own scanner
to figure out which classes should be early binded and which opline
should be replaced with NOP
solution c: like solution b, but ZendEngine do most of the work, for
example: remember all the position/pointer to opline that might be
replaced with NOP, return from zend_compile_file or
zend_compile_string so opcode cachers will catch it. do early binding
after zend_compile_file/string, which also mean after opcode cacher
stuff
Tips for those don't know zend_compile_file/string:
zend_compile_file/string is a pointer that can be overloaded by
extension/zend_extension so one can hook into the compile time
=
PS
=
XCache tricked to disable early class binding by emptying
CG(class_table) before and restore it after compile so the compiler
won't see any class that isn't in the same file.
the reason i bring up this topic again before PHP_5_3 is out is
becuase 5.3 namespace patch breaks the XCache trick and i find it no
way to trick without changing php source:
5.3 namespace code will check for CG(class_table) and see if a class
is internal class to generate different code.
namespace ns;
e.g.:
class b extends Exception // will check ::Exception at runtime
{
}
class a extends c // always ns::c
{
}
with XCache enabled:
class b extends Exception // always ns::Exception because there's no
such internal class at compile time due to XCache trick.
sorry for the long post so i mark the sections with ===s that will
help your navigation
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] early class binding revisited
Compiler shouldn't generate different code. Unqualified name is resolved
at runtime, but code should be the same whatever resolution was made.
Did you check that different code is indeed generated?
zend_compile.c
===
if (zend_hash_find(CG(class_table), lcname,
Z_STRLEN(class_name-u.constant)+1, (void**)pce) == SUCCESS
(*pce)-type == ZEND_INTERNAL_CLASS) {
/* There is an internal class with the same name
exists.
PHP will need to perform additional cheks at
run-time to
determine if we assume class in current
namespace or
internal one. */
*fetch_type |= ZEND_FETCH_CLASS_RT_NS_CHECK;
}
it's an optimization and assume that internal class never change
let me guess, if you have php_abc.so which have internal (well, 3rd
party) class abc not loaded when you encode php files with
ZendEncoder
namespace mynamespace;
var_dump(new abc());
but you do load file for production server, you still get undefined
class mynamespace::abc at runtime, internal class abc is never
checked.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] early class binding revisited
more pitfall: apc and XCache uses fast copy of opcodes for restoring opcode, but this will never work if early binding which have to modify opcodes is done after restore see apc_copy_op_array_for_execution() in apc_compile.c there is my_copy_data_exceptions(dst, src); which do a check if to deep copy. and btw, i just find fe-common.arg_info needed to be check in apc_copy_op_array() for my_copy_data_exceptions() because: in zend_compile.c zend_do_perform_implementation_check fe-common.arg_info[i].class_name = ..; any updates op_array at runtime looks evil for opcode cacher fast copy, can't we just assume opcode readonly like all elf .exe etc? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] bad test case that depends on user local ini
i have the following settings in my /etc/php.ini pcre.backtrack_limit=1 pcre.recursion_limit=1000 test case ini_get_all() tests [ext/standard/tests/general_functions/ini_get_all.phpt] FAIL. but after i remove the settings, it will PASS. Bug #43128 Very long class name causes segfault [Zend/tests/bug43128.phpt] also FAIL because i have memory_limit set to 50M in /etc/php.ini, PASS if i set it to 100M is it expected that the test case should depends on users' ini settings? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [bug in php5.3 cvs] op2 of OP_DATA which after INIT_NS_FCALL_BY_NAME is uninitialized
http://bugs.php.net/bug.php?id=43696
Description:
as you can see in zend_compile.c
opline-opcode = ZEND_INIT_NS_FCALL_BY_NAME;
ZEND_INIT_NS_FCALL_BY_NAME's op1 is initialized, so is op2
.
opline-opcode = ZEND_OP_DATA;
ZEND_OP_DATA's op1 is initialized here but op2 is not
it may not cause problem in zend executor but may in opcode
optimizers/cachers
suggested fix:
Index: zend_compile.c
===
RCS file: /repository/ZendEngine2/zend_compile.c,v
retrieving revision 1.647.2.27.2.41.2.32
diff -u -r1.647.2.27.2.41.2.32 zend_compile.c
--- zend_compile.c 27 Dec 2007 13:52:05 - 1.647.2.27.2.41.2.32
+++ zend_compile.c 28 Dec 2007 08:56:41 -
@@ -1504,6 +1504,7 @@
Z_TYPE(opline-op1.u.constant) = IS_STRING;
Z_STRLEN(opline-op1.u.constant) =
Z_STRLEN(function_name-u.constant) - prefix_len;
Z_STRVAL(opline-op1.u.constant) =
zend_str_tolower_dup(Z_STRVAL(function_name-u.constant) + prefix_len,
Z_STRLEN(opline-op1.u.constant));
+ SET_UNUSED(opline-op2);
opline-extended_value =
zend_hash_func(Z_STRVAL(opline-op1.u.constant),
Z_STRLEN(opline-op1.u.constant) + 1);
} else {
opline-opcode = ZEND_INIT_FCALL_BY_NAME;
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Syntactic improvement to array
I think it's not worth doing unless there's overwhelming support as it's not desperately needed. But I'd be interested to hear people's thoughts. It seems implementation shouldn't be an issue but I'd have to dive a bit deeper. it sure acceptable for php users and will never be a conflict to php way php is mean to be used for web pages in the first place, most ppl who works on web pages have to know what javascript is, so there isn't any difficulty for ppl to get used to either read or code [] btw, ppl use json in instead of xml may (or may not) be a good example to this topic -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] issue of current E_STRICT implemention and possible solution
the E_STRICT is an error type that issued at compile-time. and user
error handler is called, switching to runtime. mixing
runtime/compile-time is imho, not good, and cause problem in the real
world.
the flow:
script, include - compiling, issue E_STRICT - user error handler.
official bug:
1. set up user error handler
2. issue E_STRICT inside class compiling
function my_error_handler()
{
include_once debugger.class.php; // #1
$dbg = Debugger::getInstance();
...
}
is the behavior defined at point #1 ? if it is allowed, what if wrote
class Debugger { ... into debugger.class.php ? it just tell me u
cannot declare class inside another class (something like this)
3rd party bug:
XCache is doing nice on late class binding by building compiler
sandbox for ZendEngine, which clear class_table/function_table
temporarily, to make the compiler-env exactly the same every time.
but inside the sandbox, functions/classes defined before compiling, is
never exists inside the compile-time, leading to a undefined
function or undefined class error inside user error handler.
yes, the author should hack, but it's better done in php-src or ZendEngine side.
solution propose:
1. never call user error handler for E_STRICT
2. add E_STRICT to pending list and issue it after compiling. (after
returning from compile_file)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PECL-DEV] automated checking of zend_parse_parameters()
geat job. it's much faster than valgrind. and can find 64bit/be etc problems. it's something a must have like gcc printf format attribute. u may have already notice: the line number is wrong sometimes. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
