Hacker News new | past | comments | ask | show | jobs | submit login

GC theory starts with "dead objects should be collected", and then immediately retreats to "unreachable objects should be collected" since unreachable objects are dead.

But some objects are reachable, and also dead. My progress spinner advances on a timer, but nobody will ask me to draw. I'll invalidate my bitmap cache on screen resolution changes, but nobody cares about my bitmap.

Most GCs would rather leak than introduce memory unsafety. But their design biases towards leaks: weak references become this weird expensive path and that's why you don't use them routinely.




Collecting exactly the dead objects in all situations is not possible even in theory:

    function f() {
        x = Object(1)
        if (halts(some_program)) {
            return Object(2)
        } else {
            return x;
        }
    }
The contents of x will be dead or not after the assignment depending on whether some_program halts. But a GC that could determine that could solve the halting problem.


That code doesn't make any sense. Either halts() itself is a function that solves the halting problem or the else branch is a dead branch because in order to be selected halts() must have never returned.

Dynamic code is where the GC can't know if something simply has a stale reference or if the codepath that calls it simply doesn't exist yet. It's be interesting to need to tag such data appropriately as that opens up a lot of leak protection.


Yep, you're right. I should've just said that the condition of the if statement can in general be undecidable.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: