Re: Obtaining references to a given object?

Do you think you have a solution for code with a reference from previously executed code no longer in scope in the current code path that may (or may not) be GC'd at some point. So when you do your scan for references to your value the referencing code is not longer in the control-flow to the current execution point, and will be GC'd and therefore shouldn't be re-evaluated or propagate any updates.

That is the one thing the debugger method does provide, is a clear control/data-flow path to the value reference. So you can be assured there actually still is one.

Am I missing something? It is clear you have thought it through more than I have at the moment - so if I missed something obvious tell me, but I have been working on problems like this myself. It takes more code to do the data flow analysis than the whole Lua source, and it just can't handle all the corner cases. If you run the code - and that is a viable thing for you you can patch the compiler so that it generates some additional code to aid in value tracking. I am interested to hear if anyone has some better ideas - I'd love to use them in my project too.

Thanks,,

Jon

It could have been earlier in the control flow

Ret iyr qaARXEAFR EWALMIS9

On Thu, Sep 12, 2013 at 3:05 PM, Marc Lepage <mlepage@antimeta.com> wrote:

Thanks Phill, wondered about it but it sounds untenable. :-)

On Thu, Sep 12, 2013 at 2:53 PM, Phill Djonov <phill@vec3.net> wrote:

While the GC "has" that information, it isn't stored explicitly, and
it would be incredibly inefficient to obtain it from the GC . What the
GC *does* explicitly have is a giant linked list of all collectable
objects. That includes every live object (which you're interested in
scanning), every dead object (which need to be filtered out so that
they're not unintentionally resurrected), strings (which can't hold
references), and a number of internal objects like function protos,
c-closures, closures and the backing storage for each of their
upvalues, userdata objects, and a few other things along those lines.
Chances are, scanning the GC list for references to a given object
would cost about the same as a full collection. I can't imagine
wanting to incur that cost just to send a simple notification.

On Thu, Sep 12, 2013 at 7:00 AM, Marc Lepage <mlepage@antimeta.com> wrote:
> Suppose I have tables referring to tables (by their field values), or
> functions referring to upvalues (by closure).
>
> Given a table, I can know what it refers to by iterating over its contents.
> And given a closure, I can use the debug facilities to find its upvalues. I
> can do both recursively to obtain all objects or upvalues referenced.
>
> Is it possible to go in the other direction? To find all references to a
> given value (say a table) in other tables or closures (as upvalues)?
>
> Wouldn't the garbage collector have this information? It's not exposed in
> any debug facilities, is it?
>
> I'm just pondering about the idea of one object being able to notify other
> objects that reference it, without having to keep a list of listeners that
> explicitly subscribed for notifications.

--
Phill Djonov
Programmer, Tools and Graphics