Let's address another GC misconception: that you can divide GC algorithms into "perfectly precise" ones like tracing and "imprecise" ones like reference counting without cycle collection.
-
Show this thread
-
In fact, all GCs use some sort of conservative heuristic. The real problem GCs are trying to solve is to identify memory the program will never use again. This is a dynamic problem, and so a truly precise solution runs up against the halting problem.
3 replies 1 retweet 29 likesShow this thread -
Replying to @pcwalton
I see this as some sketchy pro-GC propaganda, redefining the exact, tractable problem (unreachable) to be something harder and intractable (not reached) so that inexactness sounds like just a matter of degree rather than a binary property.
1 reply 0 retweets 1 like -
Replying to @RichFelker
I don’t mean for it to be “pro-GC” or “anti-GC”. The point is that the precise tractable problem of reachability is not actually the relevant criterion.
2 replies 0 retweets 0 likes -
Replying to @pcwalton
Sure it is. If program flow is influenced by inputs that don't exist until the future, reachability is the *only* possible criterion; halting problem is not even relevant because the data you branch on doesn't exist yet.
1 reply 0 retweets 0 likes
Simple example: What if you have an array with more than 256 elements and all indices into that array are uint8_ts? In that case, those excess elements are reachable but will never be accessed. It’s safe to free those excess elements, but no GC will do that.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.