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. The
> GC cannot distinguish between different types of resources and their
> freshness, so they'll just blow away everything they can. In most real-world
> cases, you'd want to take into account both how frequently and how recently
> 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 you'd
> want to dump at the slightest hint of memory pressure (maybe even to prevent
> costly GCs from running?), while at the same time you have small-ish objects
> 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.
Resource freshness and resource type don't matter in this case. The
object just needs to be dead. I absolutely agree that weakrefs are not
a solution for caching or pooling. My comments are in reference to
scenarios where it is non-trivial to identify a point where your
object graph is dead so you can go in and break references. In those
scenarios you might use something like refcounting in order to ensure
that no one component has to be responsible for deciding 'okay, it's
dead now', and then you are subject to the types of leaks that occur
when using refcounts as your lifetime management strategy (especially
since you don't have WRs, which would otherwise mitigate the risk of
leaks caused by refcounting+cycles.)

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.

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. The
> GC cannot distinguish between different types of resources and their
> freshness, so they'll just blow away everything they can. In most real-world
> cases, you'd want to take into account both how frequently and how recently
> 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 you'd
> want to dump at the slightest hint of memory pressure (maybe even to prevent
> costly GCs from running?), while at the same time you have small-ish objects
> 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.
Resource freshness and resource type don't matter in this case. The
object just needs to be dead. I absolutely agree that weakrefs are not
a solution for caching or pooling. My comments are in reference to
scenarios where it is non-trivial to identify a point where your
object graph is dead so you can go in and break references. In those
scenarios you might use something like refcounting in order to ensure
that no one component has to be responsible for deciding 'okay, it's
dead now', and then you are subject to the types of leaks that occur
when using refcounts as your lifetime management strategy (especially
since you don't have WRs, which would otherwise mitigate the risk of
leaks caused by refcounting+cycles.)

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.