Am Do., 26. Sept. 2024 um 20:04 Uhr schrieb Daphne Preston-Kendal < d...@nonceword.org>:
> Ephemerons are the ‘right’ weak referencing primitive, but they’re also > the most expensive for garbage collectors to implement. (SRFI 124 mentions > that MIT Scheme needs five words of storage for an ephemeron vs only two > for a weak pair.) A optimizing Scheme implementation will therefore > probably ideally have multiple implementations of ephemerons, depending on > what they can prove about the relationship between the value and the key. > > For example, if the value is a type which can’t contain any pointers, such > as an immediate or a string or a number, an implementation can just > implement an ephemeron as a weak-strong pair, which is a lot cheaper to > keep track of. > > I suggest this be made explicit in the spec with a ‘should’ suggestion for > what the value in an ephemeron should be set to when the ephemeron is being > used only as a weak box for its key. (Probably #f.) This will allow > portable code that takes advantage of multiple implementations’ fast paths > for ephemerons used as weak boxes. > Thanks for this point! If we aim for maximal efficiency with regard to memory, we will have to add setters for ephemeron keys and values as well. Otherwise, mutable data structures that make use of ephemerons may need an extra wrapper by a mutable pair, vector, or record. If we go this route, the quality of the ephemeron won't be static anymore, so a fast, weak-pair path won't be possible. In other words, we will have to add an extra weak pair type as well. Marc
