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

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: 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.