> OTOH, if the program *isn't* going to use the object right away, e.g. if > object A hands object B a referece to object C so that A can call C at a > later time, you're prefetching for no purpose. Except, A had to store the object somewhere, and thus, used it. Even if it's a simple pointer assignment, A is still storing the object (or rather, a pointer to it) somewhere so it can all it later, and thus, you didn't prefetch for no purpose. > > BTW, there's an algorithm for one-bit reference counts that puts the bit > in the object pointer. That is, if the pointer has the lowest-order bit > set, and you delete that reference, you know it's safe to delete the > memory it points to (assuming objects are aligned on even addresses). > There are some complications, of course, such as temporary references > that would "stick" the count permanently to more than two, requiring > either a second bit or an "ought to be two" cache. > > > Of course that's just random speculation, but isn't random > > speculation is what memory management arguments are all about? > > The ones that are a subset of optimization arguments, yes. > > To haul the thread back toward the original topic, the real argument > against refcounting is its inability to collect cycles without > programmer intervention. Some applications and languages are guaranteed > not to create cycles ... but an interpreter for a general > object-oriented language isn't one of them Then it's a good thing we have GC specifically made to handle cycles (and only cycles) running by default, isn't it? > > -- > Frank Mitchell (frankm at bayarea.net) > > Ridiculous Lucky Captain Rabbit King! Lucky Captain Rabbit King > Nuggets are only for the youth! > -- Powerpuff Girls, "Jewel of the Aisle" > -- > http://mail.python.org/mailman/listinfo/python-list >
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4