Re: Improve worst case ephemeeron table collection speed

[Xmilia Hermit <xmilia.hermit@...>]

> - When an object is marked, how to know whether it is an ephemeron key?

I used the seventhed bit in the marked byte of GC objects. The bit is 
set when the object is detected as a white ephemeron table key. When 
marking this bit is checked and in case it is set the object is handled 
as an ephemeron key.
Note: The seventhed bit is currently used in tests to mark objects. 
However, as far as I saw the bit is only used outside of the atomic 
phase which allows to reuse it during the atomic phase.

> - Where does it link the nodes in the key? You mentioned an issue
> with Udata0, but even in other userdata (plus other objects like
> tables and functions) is there free space for another pointer?
The ephemeron keys are always white so gclink is unused and can be used 
to point to the first node.
> - How does it restore the tag of the value?
The Node has two unused padding bytes added by compilers, one of which 
was used here to save and restore the tag of the value.
> - Currently, Lua assumes that a dead key keeps its original gcvalue.
> This proposal seems to break that: If the key is never marked, its
> gcvalue will not be restored. Is that so? Maybe Lua does not need
> that assumption?
This is not a problem. First the key is really dead and so will never be 
used in a call to next. Second, the pointer points into the node vector 
of a table, so no valid GC object can have the same pointer and no 
conflicts should arise.

Regards,
Xmilia