Re: Improve worst case ephemeeron table collection speed
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Re: Improve worst case ephemeeron table collection speed
- From: Xmilia Hermit <xmilia.hermit@...>
- Date: 2022年7月22日 15:53:07 +0200
- 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