See below: > -----Original Message----- > From: Nuno Lopes [mailto:[EMAIL PROTECTED] > Sent: Tuesday, September 04, 2007 11:35 AM > To: David Wang > Cc: internals@lists.php.net; [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: Re: [PHP-DEV] Patch for macros for tracking refcount > andis_ref > > > 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. > > surely it wouldn't be the top performance GC, but I think it worths a > try. And it doesn't seem difficult to use that GC (after your patch > specially).
Figuring out the roots is *very* hard with PHP because of all the extensions managing their own zvals. I don't think it's feasible nor will it be very beneficial. > > 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. > > exactly. for most PHP requests the GC wouldn't even run. The garbage > would be collected after the request, thus reducing the latency of the > request (for Gopal pleasure :) Probably not. Executing PHP scripts is very heap intensive and if you didn't run the GC during execution you would be eating up *lots* of memory even for relatively short requests. This would have a significant impact on the # of Apache processes you can run on a given box. So I think it actually wouldn't work well for us. > > 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. > > implementing a GC from scratch is a difficult job, yes and hence my > idea to try an existenting GC. But if we look to the GCs used by e.g. > the Common Lisp implementations, we see that they have highly-tuned > and highly-performant GC implementations that take advantage of how > the internal structures are implemented. And I suspect Java does that, > too. > > Well, maybe we can find some crazy student next year to do it *hint* > :). Or maybe I get crazy too one of these days ;) (well I still have > to pick something to do for the master thesis..) Not that I think these kind of GCs are always a bad idea but they don't come without their own baggage and set of problems. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
