RE: [PHP-DEV] Patch for macros for tracking refcount and is_ref

Yes I agree that a more traditional mark-and-sweep collector would not be suitable for PHP, and as many have experienced with Java it comes with its own set of baggage. Actually I think the deterministic nature of refcounting is more suitable to Web requests esp. for sites who want to consistently serve below a certain threshold (150ms and so). Python takes the same approach btw and also has a hybrid of reference counting and then detecting cycles. Btw, I also prefer using inline functions over pure macros as it's easier to debug. The patch looks OK but I'd like to wait another 1-2 days to give others who got back from the long weekend here to review and comment on it. Andi > -----Original Message----- > From: David Wang [mailto:planetbeing@gmail.com] > Sent: Tuesday, September 04, 2007 9:38 AM > To: Nuno Lopes > Cc: internals@lists.php.net; andi@php.net; dmitry@php.net > Subject: Re: [PHP-DEV] Patch for macros for tracking refcount and > is_ref > > On 9/4/07, Nuno Lopes <nlopess@php.net> 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. 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.