On Thu, Oct 17, 2013 at 11:49 AM, david j <[email protected]> wrote: > On Thu, Oct 17, 2013 at 9:46 AM, Jonathan S. Shapiro <[email protected]>wrote: > >> There's actually a hidden pause in reference counting as well. >> Decrementing a counter can cause a cascade of deallocations. >> > > This is not a hidden cost. This is an explicit cost of an explicit action, > just like calilng free() on lots of stuff. If you don't want to incur the > cost now, then don't release the reference. >
It's not that simple. Yes, I agree that it is a cost triggered by an in-band action (releasing a reference). The problem is that the magnitude (if you prefer: cost variance) of that cost is highly unpredictable. If you are releasing a leaf object, it's a pretty low cost. If you are releasing the root of an object graph, you could be pausing for a time that is bounded only by the size of the heap. *Which makes it just as bad as halt-the-world GC*. This is why the deferred dec-buf is important. Among other things, it lets you drive those releases incrementally and gradually. The cost of that is that the return of free object storage to the re-allocatable pool is delayed, but at least with the incremental approach you are very likely (on average) to be keeping up with yourself. And in the really big cases, the background mark pass is likely to save you the bother of working through the dec-buf. GC tracing is a hidden cost, because in between two instructions which > don't allocate or deallocate you can lose alot of time to the GC. > That's not the case in *any* GC I know about. The rendesvous/syncpoints are either explicit instructions or associated with allocations. > How do you classify iOS and Python's reference counting on the spectrum of > "don't make sense" vs "apply some care"? Both of them are used for many > many very successful applications. (with quite low end-user perceived > latencies) > I'd classify both of them as sucking irredeemably. In both cases, other factors were deemed to be MUCH more important than performance, and both systems optimize for the criteria they consider important. I'm not sure if either system does release deferral. Both systems *could* do release deferral. If they aren't doing so already, implementing release deferral would improve their overall performance by 20% to 30%. Because of the legacy of manual management, implementing deferral in ObjC is much harder than implementing it for Python. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
