) if/when needed.
Andi
-Original Message-
From: Johannes Schlüter [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 03, 2008 5:11 AM
To: Andi Gutmans
Cc: Derick Rethans; Dmitry Stogov; PHP Developers Mailing List
Subject: RE: [PHP-DEV] Garbage collector patch
Hi,
On Tue, 2007-12-18
: Dmitry Stogov; PHP Developers Mailing List
Subject: RE: [PHP-DEV] Garbage collector patch
On Tue, 18 Dec 2007, Andi Gutmans wrote:
Derick Rethans wrote:
Maybe we just should put it in cvs then? Then we won't have this
issue
and other people can test it more easily as well
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
it would really be great if this could be part of CVS alredy. The patch
doesn't compile currently, I get zillions of
Zend/zend_execute.o: In function `gc_zval_check_possible_root':
php5.3-200712250730/Zend/zend_gc.h:175: undefined reference to
./buildconf --force
./config.nice
make clean
make
Dmtiry.
Markus Fischer wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
it would really be great if this could be part of CVS alredy. The patch
doesn't compile currently, I get zillions of
Zend/zend_execute.o: In function
On 25.12.2007 11:51, Markus Fischer wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
it would really be great if this could be part of CVS alredy. The patch
doesn't compile currently, I get zillions of
You didn't read 3 last messages in the thread, did you?
You have to run
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ok, I got the message :-)
Sorry for interruption, thanks, works as expected.
- - Markus
Dmitry Stogov wrote:
./buildconf --force
./config.nice
make clean
make
Dmtiry.
Markus Fischer wrote:
Hi,
it would really be great if this
On Tue, 18 Dec 2007, Rasmus Lerdorf wrote:
Ilia Alshanetsky wrote:
Putting it into CVS into a good idea, but lets create a revert point via
a tag, so we can always easily undo the patch if need be.
Making sure it is ifdef'ed nicely would let us leave it in CVS until we
get it right and if
On Wed, 19 Dec 2007, Dmitry Stogov wrote:
Derick Rethans wrote:
On Mon, 17 Dec 2007, Dmitry Stogov wrote:
Didn't I send it to you?
Maybe, maybe not :) I couldn't find it atleast.
I just tried to apply this to PHP 5.3, but it gives lots of failed chucks...
Are you sure this is
On 19.12.2007 13:20, Alexey Zakhlestin wrote:
On 12/19/07, Dmitry Stogov [EMAIL PROTECTED] wrote:
updated patch.
got an error during linking phase
You have to run this first:
./cvsclean ./buildconf
--
Wbr,
Antony Dovgal
--
PHP Internals - PHP Runtime Development Mailing List
To
On Wed, 19 Dec 2007, Alexey Zakhlestin wrote:
On 12/19/07, Dmitry Stogov [EMAIL PROTECTED] wrote:
updated patch.
got an error during linking phase
/usr/bin/ld: Undefined symbols:
_gc_globals_id
_gc_globals_ctor
_gc_zval_possible_root
_gc_collect_cycles
_gc_init
_gc_reset
On 12/19/07, Dmitry Stogov [EMAIL PROTECTED] wrote:
updated patch.
got an error during linking phase
/usr/bin/ld: Undefined symbols:
_gc_globals_id
_gc_globals_ctor
_gc_zval_possible_root
_gc_collect_cycles
_gc_init
_gc_reset
_gc_zobj_possible_root
collect2: ld returned 1 exit status
make: ***
On 12/19/07, Dmitry Stogov [EMAIL PROTECTED] wrote:
updated patch.
Great! I managed to compile it.
Works for me.
The problem mentioned here is gone: http://blog.milkfarmsoft.com/?p=52
It is now possible to continue my appserver implementation ;)
--
Alexey Zakhlestin
On Mon, 17 Dec 2007, Dmitry Stogov wrote:
Didn't I send it to you?
Maybe, maybe not :) I couldn't find it atleast.
I just tried to apply this to PHP 5.3, but it gives lots of failed
chucks... Are you sure this is the one against 5.3?
regards,
Derick
--
Derick Rethans
http://derickrethans.nl
Probably I've changed ZE after the patch was done :(
I'll rebuild it, but not today.
Dmitry.
Derick Rethans wrote:
On Mon, 17 Dec 2007, Dmitry Stogov wrote:
Didn't I send it to you?
Maybe, maybe not :) I couldn't find it atleast.
I just tried to apply this to PHP 5.3, but it gives lots of
On Tue, 18 Dec 2007, Dmitry Stogov wrote:
Derick Rethans wrote:
On Mon, 17 Dec 2007, Dmitry Stogov wrote:
Didn't I send it to you?
Maybe, maybe not :) I couldn't find it atleast.
I just tried to apply this to PHP 5.3, but it gives lots of failed chucks...
Are you sure this is
On 12/18/07, Derick Rethans [EMAIL PROTECTED] wrote:
Maybe we just should put it in cvs then? Then we won't have this issue
and other people can test it more easily as well.
+1
I want to test it, but, usually, messing with large patches is too
time-consuming :-(
having it in CVS will give me a
-Original Message-
From: Derick Rethans [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 18, 2007 7:06 AM
To: Dmitry Stogov
Cc: PHP Developers Mailing List
Subject: Re: [PHP-DEV] Garbage collector patch
Maybe we just should put it in cvs then? Then we won't have this issue
On Tue, 18 Dec 2007, Andi Gutmans wrote:
Derick Rethans wrote:
Maybe we just should put it in cvs then? Then we won't have this issue
and other people can test it more easily as well.
The only problem with that is what if people get bad
benchmarks/results and we want to pull it out?
]
Sent: Tuesday, December 18, 2007 9:20 AM
To: Andi Gutmans
Cc: Dmitry Stogov; PHP Developers Mailing List
Subject: RE: [PHP-DEV] Garbage collector patch
On Tue, 18 Dec 2007, Andi Gutmans wrote:
Derick Rethans wrote:
Maybe we just should put it in cvs then? Then we won't have
On Tue, 18 Dec 2007, Andi Gutmans wrote:
Derick Rethans wrote:
On Tue, 18 Dec 2007, Andi Gutmans wrote:
Derick Rethans wrote:
Maybe we just should put it in cvs then? Then we won't have this
issue and other people can test it more easily as well.
The only problem
Uhm I meant 5.3. I guess we can commit it but as you know, reverting
this kind of stuff later is a headache people don't like doing.
Life's not always easy ;-)
So why again life should be not easy for all PHP tree users and not only
for 3 people that work on the specific patch? CVS has
Putting it into CVS into a good idea, but lets create a revert point
via a tag, so we can always easily undo the patch if need be.
On 18-Dec-07, at 10:05 AM, Derick Rethans wrote:
On Tue, 18 Dec 2007, Dmitry Stogov wrote:
Derick Rethans wrote:
On Mon, 17 Dec 2007, Dmitry Stogov wrote:
Making sure it is ifdef'ed nicely would let us leave it in CVS until we
get it right and if it causes problems for some people they have a way
to build PHP without it. And yes, that means their build won't be
binary compatible, which is fine and no different from them trying to
revert the patch
Putting it into CVS into a good idea, but lets create a revert point via
a tag, so we can always easily undo the patch if need be.
Along with undoing all patches on the way done by other people for othe
reasones. People, what's going on? Branches function in CVS is created
EXACTLY for this
Making sure it is ifdef'ed nicely would let us leave it in CVS until we
get it right and if it causes problems for some people they have a way
Why we need non-working code in main CVS ifdef'ed if we can use
perfectly good CVS branch functionality? Just to make life harder to
ourselves and the
On Thu, 13 Dec 2007, Derick Rethans wrote:
On Thu, 13 Dec 2007, Dmitry Stogov wrote:
You test are enormous, but than you anyway. :)
I've found and fixed the problem.
Now your test suite is passed with the following results:
PHP_5_3: Tests: 7706, Failures: 45, Errors: 807,
On Fri, 7 Dec 2007, Dmitry Stogov wrote:
all your tests passed for me yesterday with memory_limit=1G.
May be it's some fresh non GC related bug :)
Try the same test with -dzend.enable_gc=0 and with unpatched PHP.
I would very interested in this bad test case, if it's really related to GC.
On Thu, 13 Dec 2007, Dmitry Stogov wrote:
You test are enormous, but than you anyway. :)
I've found and fixed the problem.
Now your test suite is passed with the following results:
PHP_5_3: Tests: 7706, Failures: 45, Errors: 807, Skipped: 347
With GC: Tests: 7706, Failures: 45, Errors:
Hi Derick,
You test are enormous, but than you anyway. :)
I've found and fixed the problem.
Now your test suite is passed with the following results:
PHP_5_3: Tests: 7706, Failures: 45, Errors: 807, Skipped: 347
With GC: Tests: 7706, Failures: 45, Errors: 804, Skipped: 347
I've no idea why
BTW the interesting fact that during Derick's test GC cycle collector
was automatically run 124 times and it collected 2,388,399 zvals.
So it really works! :)
Dmitry.
Dmitry Stogov wrote:
Hi Derick,
You test are enormous, but than you anyway. :)
I've found and fixed the problem.
Now your
'; Andi Gutmans; 'Cristian Rodriguez'; internals@lists.php.net
Subject: Re: [PHP-DEV] Garbage collector patch
Richard,
zval is such a common PHP structure that in a scope of a single script
(even a trivial one) you'd have thousands of them. Therefor even an
extra 4 bytes matter, and for people
To: [EMAIL PROTECTED]
Cc: Rasmus Lerdorf; Stas Malyshev; [EMAIL PROTECTED];
'Antony
Dovgal'; Andi Gutmans; 'Cristian Rodriguez'; internals@lists.php.net
Subject: Re: [PHP-DEV] Garbage collector patch
Richard,
zval is such a common PHP structure that in a scope of a single script
(even a trivial
On Thu, 6 Dec 2007, Dmitry Stogov wrote:
Derick Rethans wrote:
That doesn't mean it works better for me than the old one either, where I
couldn't get it to crash at all ;-) Anyway, did you try to reproduce it with
the instructions that I provided?
Yes I did. I'm looking into the
hi Derick,
all your tests passed for me yesterday with memory_limit=1G.
May be it's some fresh non GC related bug :)
Try the same test with -dzend.enable_gc=0 and with unpatched PHP.
I would very interested in this bad test case, if it's really related
to GC.
Thanks. Dmitry.
Derick Rethans
On Wed, 5 Dec 2007, Andi Gutmans wrote:
Yes that's basically true although Dmitry can probably elaborate. I
believe if the collector kicks in there'll also be a bit of a slowdown
but my main concern is to be able to turn it off because of stability.
As you can see with the update patch it
On 06.12.2007 11:21, Derick Rethans wrote:
On Wed, 5 Dec 2007, Andi Gutmans wrote:
Yes that's basically true although Dmitry can probably elaborate. I
believe if the collector kicks in there'll also be a bit of a slowdown
but my main concern is to be able to turn it off because of
Antony Dovgal schrieb:
To be honest, I can't see any crashes using standard PHP test suite.
Does the standard PHP test suite contain PHP code with reference cycles?
--
Sebastian Bergmann http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277
On Thu, 6 Dec 2007, Antony Dovgal wrote:
On 06.12.2007 11:21, Derick Rethans wrote:
On Wed, 5 Dec 2007, Andi Gutmans wrote:
Yes that's basically true although Dmitry can probably elaborate. I
believe if the collector kicks in there'll also be a bit of a slowdown
but my main concern
Derick Rethans wrote:
On Tue, 4 Dec 2007, Andi Gutmans wrote:
To clarify I meant there's a tri-state (not compiled in, compiled in
but collection turned off, compiled in but collection turned on). My
recommendation was to always compile it in but to keep collection
turned off by default.
The GC patch passes the whole php test-suite with the same bugs.
The fact that it crashes on some script doesn't mean that the patch
doesn't actually work.
Thanks. Dmitry.
Derick Rethans wrote:
On Wed, 5 Dec 2007, Andi Gutmans wrote:
Yes that's basically true although Dmitry can probably
On Thu, 6 Dec 2007, Dmitry Stogov wrote:
Derick Rethans wrote:
On Wed, 5 Dec 2007, Andi Gutmans wrote:
Yes that's basically true although Dmitry can probably elaborate.
I believe if the collector kicks in there'll also be a bit of a
slowdown but my main concern is to be able to
Dmitry Stogov wrote:
In general this patch will use more memory.
(4 bytes more for each heap allocated zval).
The only advantage is automatic cycle collection, but most web
applications doesn't make cycles.
Could it be that this code should only be enabled for the CLI sapi?
That is where I
To summarize the patch lead to approx. 5% slowdown and 3% memory
overhead for typical applications (as always, you mileage may vary
depending on your system's architecture and OS although my guesstimate
is that you will see even worse results in a 64bit environment).
Does that slowdown result
On Tue, 4 Dec 2007, Andi Gutmans wrote:
To clarify I meant there's a tri-state (not compiled in, compiled in
but collection turned off, compiled in but collection turned on). My
recommendation was to always compile it in but to keep collection
turned off by default.
That's totally fine
Is it possible to always perform (unconditionally compile in) the
necessary housekeeping tasks but stick with the current GC, so that
cycle-detection only happens when the user calls a
gc_go_find_cycles()
function? Would that significantly improve the above numbers?
Yes, that would be
To clarify I meant there's a tri-state (not compiled in, compiled in
but collection turned off, compiled in but collection turned on). My
recommendation was to always compile it in but to keep collection
turned off by default.
Do I understand it right that being compiled in, turned on and
On Wed, 5 Dec 2007, Matthias Pigulla wrote:
To summarize the patch lead to approx. 5% slowdown and 3% memory
overhead for typical applications (as always, you mileage may vary
depending on your system's architecture and OS although my guesstimate
is that you will see even worse results in
On Wed, 5 Dec 2007, Matthias Pigulla wrote:
Is it possible to always perform (unconditionally compile in) the
necessary housekeeping tasks but stick with the current GC, so that
cycle-detection only happens when the user calls a
gc_go_find_cycles()
function? Would that
On Wed, 2007-12-05 at 10:01 -0600, Brian Moon wrote:
Dmitry Stogov wrote:
In general this patch will use more memory.
(4 bytes more for each heap allocated zval).
The only advantage is automatic cycle collection, but most web
applications doesn't make cycles.
Could it be that this
On Mon, 3 Dec 2007, Andi Gutmans wrote:
The revised patch has the following advantages:
- It fixes several crash bugs
So far, my tests only see new crash bugs... :/
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x2ba1140c6930 (LWP 21108)]
0x008be4fe in
On Wed, 5 Dec 2007, Stanislav Malyshev wrote:
To clarify I meant there's a tri-state (not compiled in, compiled in but
collection turned off, compiled in but collection turned on). My
recommendation was to always compile it in but to keep collection turned
off by default.
Do I
; internals@lists.php.net
Subject: Re: [PHP-DEV] Garbage collector patch
On Wed, 5 Dec 2007, Stanislav Malyshev wrote:
To clarify I meant there's a tri-state (not compiled in, compiled
in but
collection turned off, compiled in but collection turned on). My
recommendation was to always
[mailto:[EMAIL PROTECTED]
Sent: Wednesday, 5 December 2007 5:17 AM
To: Antony Dovgal
Cc: Andi Gutmans; Cristian Rodriguez; internals@lists.php.net
Subject: Re: [PHP-DEV] Garbage collector patch
Antony Dovgal wrote:
On 04.12.2007 18:31, Andi Gutmans wrote:
You may be right longer term but shorter term
On 04.12.2007 06:00, Cristian Rodriguez wrote:
such switches only add more complexity, confusion for users and
addtional trouble to distributors.
... which I believe are going to enable this flag by default anyway,
because they don't care about performance too much.
So I agree, either do it
I believe this has to be done and it should be always on.
Having less headache is good. I will find other ways to speed up my projects
On 12/4/07, Antony Dovgal [EMAIL PROTECTED] wrote:
On 04.12.2007 06:00, Cristian Rodriguez wrote:
such switches only add more complexity, confusion for users
On Tue, 2007-12-04 at 00:00 -0300, Cristian Rodriguez wrote:
2007/12/3, Ilia Alshanetsky [EMAIL PROTECTED]:
I think the patch does have a value,
yes, it does, what worries me is the introduction of yet another
non-sense ini setting that modified the very engine behaviuor.. I
think we all
I could be wrong, of course, but my guess is that the ~3% speed decrease
a) is not really significant to 95% of the users (I mean _really_
significant; of course, everyone is going to whine about it first) and
b) is going to be eliminated over time
david
Am 04.12.2007 um 03:43 schrieb
: Tuesday, December 04, 2007 12:28 AM
To: Cristian Rodriguez
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Garbage collector patch
On 04.12.2007 06:00, Cristian Rodriguez wrote:
such switches only add more complexity, confusion for users and
addtional trouble to distributors
On 04.12.2007 18:31, Andi Gutmans wrote:
You may be right longer term but shorter term I still believe there may be
stability issues with this patch some of which we haven't figured out.
Although we did testing and found crash bugs I wouldn't trust our level of
testing to deem it stable. If
that could see some real benefits from this code. My suggestion is that
we make this feature a compile time flag, that's off by default and
What about binary compatibility?
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL
I could be wrong, of course, but my guess is that the ~3% speed decrease
a) is not really significant to 95% of the users (I mean _really_
significant; of course, everyone is going to whine about it first) and
GC is not really useful to 95% of the users either, so is 5% of the
users important
Antony Dovgal wrote:
On 04.12.2007 18:31, Andi Gutmans wrote:
You may be right longer term but shorter term I still believe there may be
stability issues with this patch some of which we haven't figured out.
Although we did testing and found crash bugs I wouldn't trust our level of
testing
MCNAUGHT
Software Developer
Synergy 8 / +617 3397 5212
[EMAIL PROTECTED]
-Original Message-
From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 5 December 2007 5:17 AM
To: Antony Dovgal
Cc: Andi Gutmans; Cristian Rodriguez; internals@lists.php.net
Subject: Re: [PHP-DEV] Garbage
/ +617 3397 5212
[EMAIL PROTECTED]
-Original Message-
From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 5 December 2007 5:17 AM
To: Antony Dovgal
Cc: Andi Gutmans; Cristian Rodriguez; internals@lists.php.net
Subject: Re: [PHP-DEV] Garbage collector patch
Antony Dovgal
[EMAIL PROTECTED] wrote:
I think having it configurable is a must. Turning it on / off via a compile
flag will not suit everyone.
Looking at the code, that isn't really possible. You could have a
switch to turn off the collection, but that won't get you your
performance back. To avoid the
1. Always compile it in but leave undocumented #ifdefs in place for
performance freaks. Those same performance freaks aren't going to care
about the binary compatibility issue since they are the same people who
build all their own stuff.
Note that breaking BC is not only about performance -
Stanislav Malyshev wrote:
1. Always compile it in but leave undocumented #ifdefs in place for
performance freaks. Those same performance freaks aren't going to care
about the binary compatibility issue since they are the same people who
build all their own stuff.
Note that breaking BC is
@lists.php.net
Subject: Re: [PHP-DEV] Garbage collector patch
Antony Dovgal wrote:
On 04.12.2007 18:31, Andi Gutmans wrote:
You may be right longer term but shorter term I still believe
there may be stability issues with this patch some of which we haven't
figured out. Although we did testing
Hi all,
Was hoping to send this off earlier but I was travelling for the past
week and had very limited email access.
As promised in the past few weeks we have spent a significant amount of
time in reviewing the garbage collector work and testing it in our
performance lab. Dmitry has been
On Dec 3, 2007 4:01 PM, Andi Gutmans [EMAIL PROTECTED] wrote:
Hi all,
Was hoping to send this off earlier but I was travelling for the past
week and had very limited email access.
As promised in the past few weeks we have spent a significant amount of
time in reviewing the garbage
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Daniel Brown wrote:
I don't know about how it worked for anyone else, but the tables
didn't display properly on Gmail, so I had a hard time keeping up with
the performance differences. If you have this in a separate file,
could you send
] Garbage collector patch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Daniel Brown wrote:
I don't know about how it worked for anyone else, but the tables
didn't display properly on Gmail, so I had a hard time keeping up
with
the performance differences. If you have
To: Andi Gutmans
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Garbage collector patch
On Dec 3, 2007 4:01 PM, Andi Gutmans [EMAIL PROTECTED] wrote:
Hi all,
Was hoping to send this off earlier but I was travelling for the
past
week and had very limited email access
@lists.php.net
Subject: Re: [PHP-DEV] Garbage collector patch
On Dec 3, 2007 4:01 PM, Andi Gutmans [EMAIL PROTECTED] wrote:
Hi all,
Was hoping to send this off earlier but I was travelling for the
past
week and had very limited email access.
As promised
Daniel Brown wrote:
If for some reason the PDF attachment didn't come through to you
on the list, let me know and I'll upload it to one of my servers for
you to download and use, as well.
The PDF didn't make it through for me. Can you upload it?
--
Edward Z. Yang
screenshot work for you?
Andi
-Original Message-
From: Daniel Brown [mailto:[EMAIL PROTECTED]
Sent: Monday, December 03, 2007 1:21 PM
To: Andi Gutmans
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Garbage collector patch
On Dec 3, 2007 4:01 PM, Andi Gutmans [EMAIL PROTECTED
Argh. Here you go: http://cvs.php.net/~andi/GC_email.pdf
-Original Message-
From: Edward Z. Yang [mailto:[EMAIL PROTECTED]
Sent: Monday, December 03, 2007 1:43 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Garbage collector patch
Daniel Brown wrote:
If for some reason
Sorry about that. Does the attached PDFed screenshot work for you?
If only we knew how to publish documents on that 'web thing.
(-:
S
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Mon, 3 Dec 2007, Andi Gutmans wrote:
Sorry about that. Does the attached PDFed screenshot work for you?
No, as you can't attach files here
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
--
PHP Internals - PHP Runtime Development Mailing List
To
On Dec 3, 2007 4:49 PM, Derick Rethans [EMAIL PROTECTED] wrote:
On Mon, 3 Dec 2007, Andi Gutmans wrote:
Sorry about that. Does the attached PDFed screenshot work for you?
No, as you can't attach files here
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no |
Sorry about that. Does the attached PDFed screenshot work for you?
Andi
-Original Message-
From: Daniel Brown [mailto:[EMAIL PROTECTED]
Sent: Monday, December 03, 2007 1:21 PM
To: Andi Gutmans
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Garbage collector patch
On Dec 3
2007/12/3, Ilia Alshanetsky [EMAIL PROTECTED]:
I think the patch does have a value,
yes, it does, what worries me is the introduction of yet another
non-sense ini setting that modified the very engine behaviuor.. I
think we all agree that there are way too many of those do we ?
. My
First of all big thanks for Dmitry and David for spending time on this
project and continuing to improve the original patch. Based on the
results so far, I think the patch does have a value, but certainly not
in a general case. Relative simple scripts have little to gain from it
and only
such switches only add more complexity, confusion for users and
addtional trouble to distributors.
FWIW, amen to that.
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Dec 3, 2007, at 1:01 PM, Andi Gutmans wrote:
Hi all,
Was hoping to send this off earlier but I was travelling for the past
week and had very limited email access.
As promised in the past few weeks we have spent a significant
amount of
time in reviewing the garbage collector work and
-Original Message-
From: Ronald Chmara [mailto:[EMAIL PROTECTED]
Sent: Monday, December 03, 2007 10:06 PM
To: Andi Gutmans
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Garbage collector patch
I'm really hesitant to even *mention* this idea, but
Could alternate memory
On Dec 3, 2007, at 10:30 PM, Andi Gutmans wrote:
-Original Message-
From: Ronald Chmara [mailto:[EMAIL PROTECTED]
What is the *actual cost and complexity* involved in implementing
(possibly many) different user-selectable memory management systems,
and what other future
87 matches
Mail list logo
