Re: newproxy()

[Florian Weimer <fw@...>]

* Roberto Ierusalimschy:

>> Can't you skip queuing the weakly-referenced object in that case,
>> marking it reachable instead?  This does not guarantee forward
>> progress, but I suppose you can't do that anyway when memory is tight.
>
> The problem is to keep everything synchronized. An object may be in
> several different weak tables and also may have a finalizer (__gc).
> Lua would have to make sure that all queues have space before doing
> anything.

I don't think you should call __gc if the object ends up in a queue
because it remains strongly reachable.  And the feature would still be
useful if the object would be enqueued only once (and kept in the
other tables).

I suppose what makes things rather murky here is that the weakly
referenced object is resurrected.  Weak references in Java are
different in that the referenced object isn't enqueued, but the weak
reference itself (and you can subclass it to add additional data).

>> Java solves this by allocating enough pointer fields when the weak
>> reference is created, so that the queue data structure can use that
>> later without further memory allocations.  This is probably not
>> suitable for Lua because you don't want the weak table machinery on
>> the ordinary table lookup path.
>
> I thought about that. The queue could be resized toghether with the
> table, out of the lookup path.

Even if the queue is shared across multiple tables?  I don't think
this will guarantee sufficient space.

AFAIK, the table entries haven't got individual link fields, so you
cannot use that space to implement an in-place queue (like Java does).