On Sat, 12 Feb 2011 12:02:14 -0500, Jonathan M Davis <jmdavisp...@gmx.com>
wrote:
On Saturday 12 February 2011 08:45:03 d coder wrote:
> If you know roughly what to do and want to take a stab at producing a
> viable patch to fix the problem, then feel free. If it's solid, it may
> get in. I don't know. It doesn't hurt to try though (as long as you're
> prepared for the fact that it may not be accepted).
Thanks for letting me know of the licensing issues. I do not think I
have the expertize required to fix this myself. So I hang my shoes
here and wait for somebody else to get stuck in a similar situation.
It is a known issue, and it should probably be fixed at some point, but
I don't
think that it's a high priority. So, there's a decent chance that it
will be
dealt with, but I have no idea when.
However, it's not generally an issue, because you shouldn't normally be
keeping
references around for stuff that isn't used anymore. The garbage
collector is
smart enough to deal with circular references and the like, so the
biggest cases
where you'd normally need weak references aren't actually a problem.
You're
trying to do something fairly abnormal here.
It's not a simple issue. The GC currently is too coarse with it's
pointer/no-pointer determination.
This would require a weak-ref to use double-dereferencing, and allocate a
pointer on the heap, a performance disaster.
For example, if weak-ref is just a simple size_t, cast to a pointer when
used, then this is still not a weak ref:
struct S
{
int *x;
weakref!int y;
}
because the whole struct is marked as containing pointers. Same goes for
anything allocated on the stack or TLS. I had to deal with this in one of
my most recent changes to the array append, since I needed to make the LRU
cache weak-ref.
I think in order for efficient generalized weak-ref to work properly, we
need precise scanning first.
-Steve
