WeakMap not the weak needed for zombie views
till at tillschneidereit.net
Mon Jul 7 02:44:35 PDT 2014
On Mon, Jul 7, 2014 at 11:21 AM, Katelyn Gadd <kg at luminance.org> wrote:
> On Mon, Jul 7, 2014 at 2:05 AM, Till Schneidereit
> <till at tillschneidereit.net> wrote:
> > While this is true, I think that, as others have argued in the discussion
> > thread I linked to and elsewhere, weakrefs are a bad solution for this.
> > GC cannot distinguish between different types of resources and their
> > freshness, so they'll just blow away everything they can. In most
> > cases, you'd want to take into account both how frequently and how
> > a resource is/was accessed. And, of equal importance, how expensive it
> is to
> > re-create. You can easily have a large, easily re-created buffer that
> > want to dump at the slightest hint of memory pressure (maybe even to
> > costly GCs from running?), while at the same time you have small-ish
> > that are expensive to re-create, so you'd only do so under serious memory
> > pressure.
> > All in all, I think the platform should expose tiered memory pressure
> > notifications, regardless of whether weakrefs are introduced for other
> > reasons.
> Maybe I misunderstand, but you seem to be talking about caching? I'm
> talking about scenarios where the userspace code can't trivially
> verify whether an object is dead, and is okay with waiting until the
> next time the GC collects.
Ah, no, you didn't - I misunderstood your argument and did indeed think it
was about caching. I'm still hesitant about this particular argument
because it seems like your framework would still have issues with delayed
cleanup if it relied on GC to do that. I know, however, that in practice
it's Hard to ensure that all references in a complex system are properly
managed (especially in scenarios involving third-party code as you
describe), so I also don't think this can be outright dismissed.
> Memory pressure notifications are a neat idea but seem like they
> expose their own GC visibility and fingerprinting concerns. They would
> at least provide a good opportunity to trigger your own user-space
> garbage collections, as long as they can occur during an event loop
> turn instead of having to wait until the next one. If you can't get a
> pressure notification while a turn is going (as a result of your
> allocations, etc), that would hurt pressure notifications' viability
> as anything other than a way to respond to memory usage changes in
> other tabs/applications.
That's a good point, and I'm pretty sure that notifications happening
during a turn (job) just won't happen. You're right about the security and
privacy concerns, I think. More fundamentally, they'd violate
run-to-completion semantics, so I don't see how they'd even work. I think
for the same reason in-turn collection of weakrefs would be impossible at
least if their post-mortem finalizers are also supposed to be run in-turn.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss