why not keep ZVAL_ADDREF ZVAL_DELREF for 3rd party source level
compatibility reason and deprecate it?
e.g.:
pecl/event/event.c: 790
ZVAL_ADDREF(ev->php_cb_arg);
On Sep 4, 2007 10:24 PM, David Wang <[EMAIL PROTECTED]> wrote:
>
> One thing to note is that I removed the existing ZVAL_ADDREF and
> that's what worries me, I dont get why people wants to introduce yet
> another switch to disable to garbage collector ( that will lead to
> different/broken behaviuor) I think there is enough non-sense already
> with the unicode.semantics switch thingy.
This switch (currently) has nothing to do
On 9/10/07, Marcus Boerger <[EMAIL PROTECTED]> wrote:
> And please no more magic switches that lead to broken code.
that's what worries me, I dont get why people wants to introduce yet
another switch to disable to garbage collector ( that will lead to
different/broken behaviuor) I think there is
Hello Andi, Cristian, David,
agreeed. We should put this into 5.3 where we'll break BC anyway. Then for
5.3 and HEAD people will have enough time to adapt (given current release
plans. The only thing left to think of is whether it makes sense to use '__'
prefix for internal stuff just like we do
Hello David,
Wednesday, September 5, 2007, 4:19:05 AM, you wrote:
> On 9/5/07, Marcus Boerger <[EMAIL PROTECTED]> wrote:
>> What is the problem with those objects? Basically there are at least three
>> seperated memory areas involved. First the zend_object container, the real
>> object and one or
It's been about 3 days since the last comment on the patch itself on
this thread and nearly a week since the patch was submitted for
comment.
Until a patch is committed, I can't publish a patch for the GC, and
until that's published, there's really nothing to debate about yet. :)
I can't commit a
On 9/8/07, Rasmus Lerdorf <[EMAIL PROTECTED]> wrote:
And yes, if it turns out
> to be 10% slower, a lot of sites are going to want to run without it.
Sad, I see you have lost the notion about who are the vast mayority of
your users.
Facebook or any top site that requires extreme performance rep
I'm not really sure what this big debate about. I'm sure that everyone
agrees (not least of all me!) that the GC patch should be thoroughly
tested for performance and stability before being released to the
public. I mean, something that affects the life-cycle of every zval
definitely has to be.
Ho
On Sep 8, 2007, at 9:31 AM, Antony Dovgal wrote:
If these companies really do worry about this %, why don't they
participate in development and/or testing?
I don't recall seeing any contributions or even feedback from
Facebook or alike, do you?
If they wait for a release to test and comp
Antony Dovgal wrote:
> On 08.09.2007 21:31, Rasmus Lerdorf wrote:
>> Facebook is quite active in APC development.
>
> I'm glad for APC, but this is a separate project (or a sub-project, whatever).
>
>> And yes, if it turns out to be 10% slower, a lot of sites are going to want
>> to run withou
On 08.09.2007 21:31, Andi Gutmans wrote:
> Uhm I didn't mean to make this about one company or another (it was just an
> example,
> and btw, I think they've contributed to APC :) and this discussion is going
> very much
> of track. I guess you either didn't understand what I was saying or don't
On 08.09.2007 21:31, Rasmus Lerdorf wrote:
> Facebook is quite active in APC development.
I'm glad for APC, but this is a separate project (or a sub-project, whatever).
> And yes, if it turns out to be 10% slower, a lot of sites are going to want
> to run without it.
Right, but saying that we
Antony Dovgal wrote:
> On 08.09.2007 19:34, Andi Gutmans wrote:
>> When we all get a copy of the patch and get a chance to test it seriously
>> we'll know more.
>> I'm all in favor of having GC and very enthusiastic about this coming about
>> but I doubt you can
>> call it well enough tested. Wh
#x27;re running on empty...
Andi
> -Original Message-
> From: Antony Dovgal [mailto:[EMAIL PROTECTED]
> Sent: Saturday, September 08, 2007 9:32 AM
> To: Andi Gutmans
> Cc: internals@lists.php.net
> Subject: Re: FW: [PHP-DEV] Patch for macros for tracking refcount and
> is_
On 08.09.2007 19:34, Andi Gutmans wrote:
> When we all get a copy of the patch and get a chance to test it seriously
> we'll know more.
> I'm all in favor of having GC and very enthusiastic about this coming about
> but I doubt you can
> call it well enough tested. When we made memory manager ch
ian Rodriguez [mailto:[EMAIL PROTECTED]
> Sent: Friday, September 07, 2007 11:54 PM
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] Patch for macros for tracking refcount and
> is_ref
>
> On 9/7/07, Andi Gutmans <[EMAIL PROTECTED]> wrote:
>
> >Let's not run
On 9/7/07, Andi Gutmans <[EMAIL PROTECTED]> wrote:
>Let's not run before we walk.
The GC already "walks."
>There's still testing and review and some stabilizing period we
should be doing
if it is disabled by default it is unlikely that people will test it
with real life code even more with in y
On Sat, 8 Sep 2007, David Wang wrote:
> I don't even have a CVS account yet so I can't commit this patch. I
> haven't needed it so I never requested it. However, I will soon in
> order to quickly respond to GC-related bugs that might crop up. Could
> one be granted to me with the appropriate karma
> As far as I'm concerned you can commit it with ZEND_GC. If you don't
> have karma let me know and we'll commit it.
I don't even have a CVS account yet so I can't commit this patch. I
haven't needed it so I never requested it. However, I will soon in
order to quickly respond to GC-related bugs th
ns
> Cc: Cristian Rodriguez; internals@lists.php.net
> Subject: Re: [PHP-DEV] Patch for macros for tracking refcount and
> is_ref
>
> Here's my analysis of what the options are:
>
> In my mind, the macros patch is actually unrelated to the GC patch. It
> is a Good Idea (tm) to
Here's my analysis of what the options are:
In my mind, the macros patch is actually unrelated to the GC patch. It
is a Good Idea (tm) to use macros to manipulate refcounts no matter if
the GC is enabled, disabled, present in the source, or not added at
all. The only question is whether to break s
the macros are used and
we will find a way to do that.
Andi
> -Original Message-
> From: David Wang [mailto:[EMAIL PROTECTED]
> Sent: Friday, September 07, 2007 8:38 AM
> To: Cristian Rodriguez
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] Patch for mac
Not source compatibility.
> -Original Message-
> From: Cristian Rodriguez [mailto:[EMAIL PROTECTED]
> Sent: Friday, September 07, 2007 1:06 AM
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] Patch for macros for tracking refcount and
> is_ref
>
> On 9/7/07
> -Original Message-
> From: Derick Rethans [mailto:[EMAIL PROTECTED]
> Sent: Friday, September 07, 2007 12:09 AM
> To: Andi Gutmans
> Cc: David Wang; Marcus Boerger; Nuno Lopes; internals@lists.php.net;
> [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: RE: [PHP-DEV]
> ps: remember to change the Zend/PHP API number as well ;)
Done.
I personally think having a ZEND_GC switch sort of defeats the purpose
of forcing everyone to start using the macros (whether or not we want
the GC), which is something we want to do anyway. However, here are
the two versions of th
On 9/7/07, Derick Rethans <[EMAIL PROTECTED]> wrote:
> But you might want to wonder if that's not a good thing? Without the
> prefix there will be no indication for third party extensions that they
> might be doing something that's not going to work nicely with the new GC
> anymore. I'd prefer it
On Thu, 6 Sep 2007, Andi Gutmans wrote:
> In general the patch is fine.
> The only thing which I'd like to change is to make sure the __gc naming
> is in an #if ZEND_GC for now otherwise we'll be breaking lots of third
> party libraries and PECL extensions.
But you might want to wonder if that's
On 9/7/07, Andi Gutmans <[EMAIL PROTECTED]> wrote:
> The only thing which I'd like to change is to make sure the __gc naming
> is in an #if ZEND_GC for now otherwise we'll be breaking lots of third
> party libraries and PECL extensions.
Here's an updated version: http://zoo.cs.yale.edu/~yw226/macr
g [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, September 05, 2007 10:47 PM
> To: Marcus Boerger
> Cc: Nuno Lopes; internals@lists.php.net; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: [PHP-DEV] Patch for macros for tracking refcount and
> is_ref
>
> > In my own code, I have
> In my own code, I have a "__gc" on refcount and is_ref so I get thrown
> an error if there's a place I failed to macroize. I removed that for
> this patch, but that's a very good point. If there are no objections,
> that or another prefix or suffix can be put back into the patch.
I've posted ano
On 9/5/07, Marcus Boerger <[EMAIL PROTECTED]> wrote:
> What is the problem with those objects? Basically there are at least three
> seperated memory areas involved. First the zend_object container, the real
> object and one or several zvals. The gc would simply have to decrease
> refcount on zend_o
> -Original Message-
> From: Marcus Boerger [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, September 04, 2007 2:12 PM
> To: Andi Gutmans
> Cc: Derick Rethans; David Wang; Nuno Lopes; internals@lists.php.net;
> [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: [PHP-DEV]
; [EMAIL PROTECTED];
>> [EMAIL PROTECTED]
>> Subject: RE: [PHP-DEV] Patch for macros for tracking refcount and
>> is_ref
>>
>> On Tue, 4 Sep 2007, Andi Gutmans wrote:
>>
>> > Btw, when can you make a PHP 5.2.x version of the patch available so
>&g
On Tue, 4 Sep 2007, Andi Gutmans wrote:
> On Tuesday, September 04, 2007 11:57 AM, Derick Rethans wrote:
> >
> > On Tue, 4 Sep 2007, Andi Gutmans wrote:
> >
> > > Btw, when can you make a PHP 5.2.x version of the patch available so
> > > that we can start playing around with it and test it?
> >
> -Original Message-
> From: Derick Rethans [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, September 04, 2007 11:57 AM
> To: Andi Gutmans
> Cc: David Wang; Nuno Lopes; internals@lists.php.net; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: RE: [PHP-DEV] Patch fo
On Tue, 4 Sep 2007, Marcus Boerger wrote:
> Tuesday, September 4, 2007, 6:38:17 PM, you wrote:
>
> > If ever a version of this patch is committed, you'll be able to see
> > that the cycle collector touches the whole reference counting mess
> > extremely minimally, which is why it was relatively s
Hello David,
Tuesday, September 4, 2007, 6:38:17 PM, you wrote:
> On 9/4/07, Nuno Lopes <[EMAIL PROTECTED]> wrote:
>> It can also have some use if we
>> decide to investigate the usage of an off-the-shelf (conservative)
>> garbage collector such as Boehm's (maybe in next year's SoC).
>>
> As an
On Tue, 4 Sep 2007, Andi Gutmans wrote:
> Btw, when can you make a PHP 5.2.x version of the patch available so
> that we can start playing around with it and test it?
THis is the 5.2 version... it still needs to be ported to HEAD.
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no
php.net; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: [PHP-DEV] Patch for macros for tracking refcount and
> is_ref
>
> On 9/4/07, Nuno Lopes <[EMAIL PROTECTED]> wrote:
> > It can also have some use if we
> > decide to investigate the usage of an off-the-shelf
TECTED]; [EMAIL PROTECTED]
> Subject: Re: [PHP-DEV] Patch for macros for tracking refcount and
> is_ref
>
> On 9/4/07, Nuno Lopes <[EMAIL PROTECTED]> wrote:
> > It can also have some use if we
> > decide to investigate the usage of an off-the-shelf (conservative)
> >
Off the shelf garbage collectors such as BDW would be inappropriate
because we use some weird kinds of "pointers" (such as object handles)
stored in weird kinds of ways (such as a zend_hash object). I think it
would be pretty inefficient, since those implementations just scan the
stack, registers
> currently you only have one statement in each of those functions..
> anyway it's not critical to have static inline functions.
I will need to have them (multiple statements) for the cycle
collection code, and I don't think there are many situations involving
changing the way reference counting i
On 9/4/07, Nuno Lopes <[EMAIL PROTECTED]> wrote:
> It can also have some use if we
> decide to investigate the usage of an off-the-shelf (conservative)
> garbage collector such as Boehm's (maybe in next year's SoC).
>
As an aside, I was also thinking about this throughout the course of
the project
About the patch, the zval_*_p() functions don't really need to exist..
they can be macros as well.
As I said, if those were macros, it would be very difficult to squeeze
more than one statement into them.
Having multiple statements in Z_DELREF_P will also break that code. It
seems to me inline
> About the patch, the zval_*_p() functions don't really need to exist..
> they can be macros as well.
As I said, if those were macros, it would be very difficult to squeeze
more than one statement into them.
Consider the usage in Zend/zend_execute.c:
if (!Z_DELREF_P(z)) {
I think this is a pretty good idea. It can also have some use if we
decide to investigate the usage of an off-the-shelf (conservative)
garbage collector such as Boehm's (maybe in next year's SoC).
About the patch, the zval_*_p() functions don't really need to exist..
they can be macros as w
> Shouldn't that be
>
> +#define always_inline inline
>
> ?
Yes, sorry, I just fixed that a moment ago (and the file the link is
pointing to should be correct).
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
W liście David Wang z dnia wtorek, 4 września 2007 16:24:
> http://zoo.cs.yale.edu/~yw226/macros.diff.txt
>
> Comments?
+#define always_inline inlinue
Shouldn't that be
+#define always_inline inline
?
(in zend.h)
--
Paweł Stradomski
--
PHP Internals - PHP Runtime Development Mailing List
To
Hi,
This is another shot at a patch to manage refcount and is_ref of zvals
with macros. The macros are implemented with inline functions that are
forcibly inlined (so they will behave the same as macros). This will
make it possible to put multiple statements in each macro later on for
garbage coll
49 matches
Mail list logo
