Patch for macros for tracking refcount and is_ref

Yes, sorry, I just fixed that a moment ago (and the file the link is pointing to should be correct).

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)) { Z_SET_REFCOUNT_P(z, 1); Suppose I wanted to do the following in Z_DELREF_P(z): "some_function(z); z->refcount--;" Defining the macro as that would break that section of the code. Also, suppose I have code like this: if(some_condition) { Z_DELREF_P(z); Having multiple statements in Z_DELREF_P will also break that code. It seems to me inline functions are the best solution (the second best solution would be to put braces around the statements in the define, but then no return value would be possible).

Do you mean ZEND_VM_ALWAYS_INLINE? There is a ZEND_VM_ALWAYS_INLINE #define that does something similar to my "always_inline". However, it doesn't work for Microsoft compilers, and since it doesn't include the "inline" keyword within its definition, I'd have to change the meaning of it in order to fix that. As far as I can tell, it's not referenced by any code at all, but that still might be a bad idea.

On 9/4/07, Nuno Lopes <nlopess@php.net> wrote:

As an aside, I was also thinking about this throughout the course of the project. It's said that reference counting is the slowest form of garbage collection since the reference counts must constantly be maintained. Changing to a tracing garbage collector won't require these macros, because reference counts would be eliminated altogether. However, it would be sort of a big pain to implement 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 and heap and we're trying to do GC not for the PHP interpreter, but for the code the PHP interpreter is running. I have a certain suspicion that a traditional mark-and-sweep collector might be faster if just on the virtue of eliminating the refcount field and getting rid of tons of cache misses that way. For just displaying page, there wouldn't be much memory used and that's all freed at the end of a request anyway: all of that reference counting overhead would just disappear. For larger scripts that use a lot of memory, the only problem would be pause times but in most real life cases, it seems the total time would be shorter than reference counting. However, I'm not sure if that would be the case in PHP: rummaging through objects scattered all over memory would result in a lot of cache misses. The question is whether that is greater than all the misses we're currently having just managing the refcount. However, answering that question would require implementing the thing, and that honestly seems like it would be a bit of a nightmare. Roots would include zvals linked to PHP variables, the stack of the running PHP code, and the stack and heap of the PHP interpreter itself. It would've been far easier if PHP had been designed from the ground up to use some sane way of managing memory, but with the current situation, with extensions depending on reference counting, it's pretty difficult. 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 safe to implement.