[PHP-DEV] PHP 6 Bug Summary Report
PHP 6 Bug Database summary - http://bugs.php.net/ Num Status Summary (66 total -- which includes 28 feature requests) ===[*General Issues]== 26771 Suspended register_tick_funtions crash under threaded webservers ===[Apache2 related]== 44083 Open virtual() not outputting results if zlib.output_compression = On ===[Arrays related]=== 35277 Suspended incorrect recursion detection 41758 Assigned SORT_LOCALE_STRING broken for sort() in PHP6 43109 Open array_intersect() emits unexpected no of notices when 2d array is passed as arg ===[Class/Object related]= 41461 Assigned E_STRICT notice when overriding methods not defined by an Interface in hierarchy ===[COM related]== 45836 Open cannot use com ===[Compile Failure]== 42606 Open unicode/constants.c relies on ICU draft api 44502 Suspended Compiling ok with MySQL 5.0 ===[Filesystem function related]== 42110 Open fgetcsv doesn't handle ""\n correctly in multiline csv record 44034 Open FILE_IGNORE_NEW_LINES in FILE does not work as expected when lines end in \r\n 45585 Open fread() return value for EOF inconsistent between PHP 5 and 6 ===[GD related]=== 34670 Assigned imageTTFText for Indian scripts (Devanagari) 34992 Assigned imageconvolution does not respect alpha ===[I18N and L10N related] 42471 Open locale_set_default returns true on invalid locales ===[mbstring related]= 44868 Open Replaces UTF-8 symbol with incorrect symbol ===[MySQL related] 44076 Open mysql_result returns nothing with blob 45246 Open make error after ./configure --with-mysql ===[ODBC related]= 39756 Assigned Crashes in fetching resultsets with LONG ASCII columns from MaxDB ===[OpenSSL related]== 25614 Suspended openssl_pkey_get_public() fails when given a private key ===[Other web server]= 26495 Suspended Using WebSite Pro 2.5 with ISAPI, cookies are not working ===[PDO related]== 35368 Suspended PDO query does not work properly with serialize 42079 Open pdo_mysql always links to 3.x libraries (== PDO* in HEAD is out-dated) ===[Performance problem]== 42528 Open Out of "char"(8-bit) range value doesn't roll back, with uni-code ON. ===[Program Execution] 39992 Open proc_terminate() leaves children of child running 43784 Assigned escapeshellarg removes % from given string ===[Regexps related]== 44923 Open ereg functions are not unicode aware: provide wrapper functions in PCRE ===[Reproducible crash]=== 45107 Open setting ext_dir to "./" (and other ini settings) causes apache crash ===[Scripting Engine problem]= 42194 Open $argc/$argv[] won't work when .php extension is assigned to php.exe ===[Session related]== 44860 Open session_encode() fails for php_binary serializer ===[Strings related]== 44075 Verified strtok misbehaving 45566 Open Strict comparision on $_SERVER values fail ===[Unicode Engine related]=== 45087 Open Illegal or truncated character in input 45248 Feedback Shfift_JIS encoded characters in PHP script cause an error. ===[URL related]== 45602 Open urlencode/urldecode should use ASCII encoding ===[XML related]== 45022 Open Can't get php6 snap to ./configure on mac, fails at libxml2 ===[XSLT related]= 38218 Assigned php:functionString tries to access objects with their names in lowercase ===[Zlib Related]= 30153 Suspended FATAL erealloc() error when using gzinflate() Assigned bugs and feature requests (reminders sent): andrei
[PHP-DEV] CVS Account Request: pinkcrow
Improvement of performance -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS Account Request: pinkcrow
On 18.08.2008 15:06, Valeriu Buzila wrote: Improvement of performance You don't need a CVS account to start preparing patches and working with the community. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] ZTS as fast as non-ZTS
Hi Arnaud, The patch looks very interesting. I think it may be committed to the HEAD in the nearest future. I don't have time to look into all details in the moment. Could you explain why --with-tsrm-full-__thread-tls doesn't work with dlopen() however --with-tsrm-__thread-tls does? Did you test the patch with DSO extensions? It would be interesting to try the same idea on Windows with VC. Thanks. Dmitry. Arnaud Le Blanc wrote: Hi, Currently the way globals work forces to pass a thread-local-storage pointer across function calls, which involves some overhead. Also, not all functions get the pointer as argument and need to use TSRMLS_FETCH(), which is slow. For instance emalloc() involves a TSRMLS_FETCH(). An other overhead is accessing globals, using multiple pointers in different locations. The following patch caches each global address in a native TLS variable so that accessing a global is as simple as global_name->member. This removes the requirement of passing the tls pointer across function calls, so that the two major overheads of ZTS builds are avoided. Globals can optionally be declared statically, which speeds up things a bit. Results in bench.php: non-ZTS:3.7s ZTS unpatched: 5.2s ZTS patched:4.0s ZTS patched and static globals: 3.8s The patch introduces two new macros: TSRMG_D() (declare) and TSRMG_DH() (declare, for headers) to declare globals, instead of the current "ts_rsrc_id foo_global_id". These macros declare the global id, plus the __thread pointer to the global storage. ts_allocate_id now takes one more callback function as argument to bind the global pointer to its storage. This callback is declared in TSRMG_D[H](). As all TSRMLS_* macros now does nothing, it is needed to call ts_resource(0) explicitly at least one time in each thread to initialize its storage. A new TSRMLS_INIT() macro as been added for this purpose. All this is disabled by default. --with-tsrm-__thread-tls enables the features of the patch, and --with-tsrm-full-__thread-tls enables static declaration of globals. It as been tested on Linux compiled with --disable-all in CLI and a bit in Apache2 with the worker MPM. Known issues: - Declaring globals statically (--with-tsrm-full-__thread-tls) causes troubles to dlopen(), actually Apache wont load the module at runtime (it works with just --with-tsrm-__thread-tls). - The patch assumes that all resources are ts_allocate_id()'ed before any other thread calls ts_allocate_id or ts_resource_ex(), which is possibly not the case. The patch needs some tweaks and does not pretend to be included in any branch, but I would like to have some comments on it. The patch: http://arnaud.lb.s3.amazonaws.com/__thread-tls.patch Regards, Arnaud -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] ZTS as fast as non-ZTS
Hi! The following patch caches each global address in a native TLS variable so that accessing a global is as simple as global_name->member. This removes the requirement of passing the tls pointer across function calls, so that the two major overheads of ZTS builds are avoided. I think it would be great to use __thread there. But I think if we have working __thread, why not have real globals use it, without all that TSRMG stuff? Having 3 different variants of TSRM support seems excessive. Now, the question is can we reliably detect if we have working __thread - or, in other words, are there compilers which would accept __thread but do not implement it correctly, and can those be identified automatically? If we use static declaration with __thread, then as far as I can see there is no need for separate IDs and all complications following from that. - Declaring globals statically (--with-tsrm-full-__thread-tls) causes troubles to dlopen(), actually Apache wont load the module at runtime (it works with just --with-tsrm-__thread-tls). What is the problem there, could you elaborate? -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] ZTS as fast as non-ZTS
Hi, On Monday 18 August 2008 19:46:46 Dmitry Stogov wrote: > Hi Arnaud, > > The patch looks very interesting. > I think it may be committed to the HEAD in the nearest future. > I don't have time to look into all details in the moment. > > Could you explain why --with-tsrm-full-__thread-tls doesn't work with > dlopen() however --with-tsrm-__thread-tls does? That's due to the way TLS works internally. Actually I need further reading on that. > > Did you test the patch with DSO extensions? I will, but I guess that will be behaves like another shared library dlopen()ed by Apache. > > It would be interesting to try the same idea on Windows with VC. I will try too. > > Thanks. Dmitry. > > Arnaud Le Blanc wrote: > > Hi, > > > > Currently the way globals work forces to pass a thread-local-storage pointer > > across function calls, which involves some overhead. Also, not all functions > > get the pointer as argument and need to use TSRMLS_FETCH(), which is slow. For > > instance emalloc() involves a TSRMLS_FETCH(). An other overhead is accessing > > globals, using multiple pointers in different locations. > > > > The following patch caches each global address in a native TLS variable so > > that accessing a global is as simple as global_name->member. This removes the > > requirement of passing the tls pointer across function calls, so that the two > > major overheads of ZTS builds are avoided. > > > > Globals can optionally be declared statically, which speeds up things a bit. > > > > Results in bench.php: > > non-ZTS:3.7s > > ZTS unpatched: 5.2s > > ZTS patched:4.0s > > ZTS patched and static globals: 3.8s > > > > The patch introduces two new macros: TSRMG_D() (declare) and TSRMG_DH() > > (declare, for headers) to declare globals, instead of the current "ts_rsrc_id > > foo_global_id". These macros declare the global id, plus the __thread pointer > > to the global storage. > > > > ts_allocate_id now takes one more callback function as argument to bind the > > global pointer to its storage. This callback is declared in TSRMG_D[H](). > > > > As all TSRMLS_* macros now does nothing, it is needed to call ts_resource(0) > > explicitly at least one time in each thread to initialize its storage. A new > > TSRMLS_INIT() macro as been added for this purpose. > > > > All this is disabled by default. --with-tsrm-__thread-tls enables the features > > of the patch, and --with-tsrm-full-__thread-tls enables static declaration of > > globals. > > > > It as been tested on Linux compiled with --disable-all in CLI and a bit in > > Apache2 with the worker MPM. Known issues: > > - Declaring globals statically (--with-tsrm-full-__thread-tls) causes troubles > > to dlopen(), actually Apache wont load the module at runtime (it works with > > just --with-tsrm-__thread-tls). > > - The patch assumes that all resources are ts_allocate_id()'ed before any > > other thread calls ts_allocate_id or ts_resource_ex(), which is possibly not > > the case. > > > > The patch needs some tweaks and does not pretend to be included in any branch, > > but I would like to have some comments on it. > > > > The patch: http://arnaud.lb.s3.amazonaws.com/__thread-tls.patch > > > > Regards, > > > > Arnaud > > > > > Regards, Arnaud -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] ZTS as fast as non-ZTS
Hi, On Monday 18 August 2008 22:26:20 Stanislav Malyshev wrote: > Hi! > > > The following patch caches each global address in a native TLS variable so > > that accessing a global is as simple as global_name->member. This removes the > > requirement of passing the tls pointer across function calls, so that the two > > major overheads of ZTS builds are avoided. > > I think it would be great to use __thread there. But I think if we have > working __thread, why not have real globals use it, without all that > TSRMG stuff? Having 3 different variants of TSRM support seems excessive. I'm agree with you, but actually TSRM does more that just allocating and storing globals. For instance it keeps track of constructors and destructors so that it can call them automatically when a new thread starts or stops. It also allows to retrieve the globals of an other thread, etc. > > Now, the question is can we reliably detect if we have working __thread > - or, in other words, are there compilers which would accept __thread > but do not implement it correctly, and can those be identified > automatically? For that I checked how the glibc chooses to use __thread or not. Actually it just tries to compile a source like I do in the patch. But as TLS handling needs the help of the libc itself, and the glibc knows it can handle TLS, I guess we will need to do write a more complete test to check if it works and if it works as we expect it to work. > > If we use static declaration with __thread, then as far as I can see > there is no need for separate IDs and all complications following from > that. > > > - Declaring globals statically (--with-tsrm-full-__thread-tls) causes troubles > > to dlopen(), actually Apache wont load the module at runtime (it works with > > just --with-tsrm-__thread-tls). > > What is the problem there, could you elaborate? > -- > Stanislav Malyshev, Zend Software Architect > [EMAIL PROTECTED] http://www.zend.com/ > (408)253-8829 MSN: [EMAIL PROTECTED] > Regards, Arnaud -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] ZTS as fast as non-ZTS
Hi! I'm agree with you, but actually TSRM does more that just allocating and storing globals. For instance it keeps track of constructors and destructors so that it can call them automatically when a new thread starts or stops. It also allows to retrieve the globals of an other thread, etc. OK, so we still need to register ctors/dtors, but we don't need to access globals in a roundabout way anymore. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [PATCH] ZTS as fast as non-ZTS
Hi Arnaud, I remember that at the time we looked at thread local storage and there were some real issues with it. I can't remember what as it was about 7+ years ago. I will ask Zeev if he remembers and if not search my archives (don't have years prior to 2007 indexed :'( ). Andi > -Original Message- > From: Arnaud Le Blanc [mailto:[EMAIL PROTECTED] > Sent: Saturday, August 16, 2008 7:19 PM > To: PHP Development > Subject: [PHP-DEV] [PATCH] ZTS as fast as non-ZTS > > Hi, > > Currently the way globals work forces to pass a thread-local-storage pointer > across function calls, which involves some overhead. Also, not all functions > get the pointer as argument and need to use TSRMLS_FETCH(), which is slow. For > instance emalloc() involves a TSRMLS_FETCH(). An other overhead is accessing > globals, using multiple pointers in different locations. > > The following patch caches each global address in a native TLS variable so > that accessing a global is as simple as global_name->member. This removes the > requirement of passing the tls pointer across function calls, so that the two > major overheads of ZTS builds are avoided. > > Globals can optionally be declared statically, which speeds up things a bit. > > Results in bench.php: > non-ZTS: 3.7s > ZTS unpatched:5.2s > ZTS patched: 4.0s > ZTS patched and static globals: 3.8s > > The patch introduces two new macros: TSRMG_D() (declare) and TSRMG_DH() > (declare, for headers) to declare globals, instead of the current "ts_rsrc_id > foo_global_id". These macros declare the global id, plus the __thread pointer > to the global storage. > > ts_allocate_id now takes one more callback function as argument to bind the > global pointer to its storage. This callback is declared in TSRMG_D[H](). > > As all TSRMLS_* macros now does nothing, it is needed to call ts_resource(0) > explicitly at least one time in each thread to initialize its storage. A new > TSRMLS_INIT() macro as been added for this purpose. > > All this is disabled by default. --with-tsrm-__thread-tls enables the features > of the patch, and --with-tsrm-full-__thread-tls enables static declaration of > globals. > > It as been tested on Linux compiled with --disable-all in CLI and a bit in > Apache2 with the worker MPM. Known issues: > - Declaring globals statically (--with-tsrm-full-__thread-tls) causes troubles > to dlopen(), actually Apache wont load the module at runtime (it works with > just --with-tsrm-__thread-tls). > - The patch assumes that all resources are ts_allocate_id()'ed before any > other thread calls ts_allocate_id or ts_resource_ex(), which is possibly not > the case. > > The patch needs some tweaks and does not pretend to be included in any branch, > but I would like to have some comments on it. > > The patch: http://arnaud.lb.s3.amazonaws.com/__thread-tls.patch > > Regards, > > Arnaud > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] ZTS as fast as non-ZTS
Hi, Yes, I have looked for the issue with --with-tsrm-full-__thread-tls and there are effectively some issues. When building PIC code, the used TLS model is a static model which does not allow modules to be loaded at run-time. glibc's dlopen() sometimes allow such code to be loaded at runtime when it finds some free memory, that's why --with- tsrm-__thread-tls works, but it is not expected to always work. So when building PIC code that's expected to work only when the server/application links the PHP module, or when using LD_PRELOAD, etc. Building non-PIC code allows to use a dynamic TLS model, which allows to load modules a run-time, but it is less efficient (4.8s in bench.php, still faster than unpatched version, even non-PIC, but less efficient). Regards, Arnaud On Tuesday 19 August 2008 06:18:51 Andi Gutmans wrote: > Hi Arnaud, > > I remember that at the time we looked at thread local storage and there > were some real issues with it. I can't remember what as it was about 7+ > years ago. > I will ask Zeev if he remembers and if not search my archives (don't > have years prior to 2007 indexed :'( ). > > Andi > > > > > > -Original Message- > > From: Arnaud Le Blanc [mailto:[EMAIL PROTECTED] > > Sent: Saturday, August 16, 2008 7:19 PM > > To: PHP Development > > Subject: [PHP-DEV] [PATCH] ZTS as fast as non-ZTS > > > > Hi, > > > > Currently the way globals work forces to pass a thread-local-storage > pointer > > across function calls, which involves some overhead. Also, not all > functions > > get the pointer as argument and need to use TSRMLS_FETCH(), which is > slow. For > > instance emalloc() involves a TSRMLS_FETCH(). An other overhead is > accessing > > globals, using multiple pointers in different locations. > > > > The following patch caches each global address in a native TLS > variable so > > that accessing a global is as simple as global_name->member. This > removes the > > requirement of passing the tls pointer across function calls, so that > the two > > major overheads of ZTS builds are avoided. > > > > Globals can optionally be declared statically, which speeds up things > a bit. > > > > Results in bench.php: > > non-ZTS:3.7s > > ZTS unpatched: 5.2s > > ZTS patched:4.0s > > ZTS patched and static globals: 3.8s > > > > The patch introduces two new macros: TSRMG_D() (declare) and > TSRMG_DH() > > (declare, for headers) to declare globals, instead of the current > "ts_rsrc_id > > foo_global_id". These macros declare the global id, plus the __thread > pointer > > to the global storage. > > > > ts_allocate_id now takes one more callback function as argument to > bind the > > global pointer to its storage. This callback is declared in > TSRMG_D[H](). > > > > As all TSRMLS_* macros now does nothing, it is needed to call > ts_resource(0) > > explicitly at least one time in each thread to initialize its storage. > A new > > TSRMLS_INIT() macro as been added for this purpose. > > > > All this is disabled by default. --with-tsrm-__thread-tls enables the > features > > of the patch, and --with-tsrm-full-__thread-tls enables static > declaration of > > globals. > > > > It as been tested on Linux compiled with --disable-all in CLI and a > bit in > > Apache2 with the worker MPM. Known issues: > > - Declaring globals statically (--with-tsrm-full-__thread-tls) causes > troubles > > to dlopen(), actually Apache wont load the module at runtime (it works > with > > just --with-tsrm-__thread-tls). > > - The patch assumes that all resources are ts_allocate_id()'ed before > any > > other thread calls ts_allocate_id or ts_resource_ex(), which is > possibly not > > the case. > > > > The patch needs some tweaks and does not pretend to be included in any > branch, > > but I would like to have some comments on it. > > > > The patch: http://arnaud.lb.s3.amazonaws.com/__thread-tls.patch > > > > Regards, > > > > Arnaud > > > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
