Weak ephemerons

[Elarnon]

In #10737, a new immutable API for ephemerons was introduced for the benefits of the multicore runtime. There, @kayceesrk advocated for the stronger requirement of a GC-oblivious API, because a GC-aware API could have surprising behaviors.

At the time, the PR mentioned that the runtime would only implement the Bucket module (which presumably would be GC-oblivious), but it looks like that is not the case and the low-level Obj.Ephemeron API has not changed. Moreover, the example provided by @kayceesrk to advocate for GC-obliviousness requires an incorrect ordering of set_key and set_data, which the immutable API prevents by not exposing these functions (and calling them in the correct order in make). I don't know if there are plans to separate the implementation of weak references and gc-oblivious ephemerons in the future.

Would the team be open to implementing a function weak_query : ('k, 'd) t -> ('k * 'd) option in Ephemeron.K1.t? Alternatively, to new modules Ephemeron.Weak.K1 etc. (with distinct types) where query has the signature above? If so, I am happy to write the corresponding PR.

For context, I have a program where I am storing an "undo trail" of reference writes to restore the old values later. I would like to avoid the undo trail forcing references to stay alive when they would otherwise be dead. I could use a pair 'a ref Weak.t * ('a ref, 'a) Ephemeron.K1.t, but since 'a ref Weak.t really is ('a ref, unit) Ephemeron.K1.t, it seems wasteful.

[lpw25]

I think the intention in the long run is still to implement the Bucket module directly in the runtime and implement Weak separately. I think we would like to maintain the GC-obliviousness of the Bucket module and the ephemeron interfaces built on top of it. So I think your: 'a ref Weak.t * ('a ref, 'a) Ephemeron.K1.t approach is the best one here.

[Elarnon]

OK, that is somewhat unfortunate but makes sense if there is still plans to split the implementations. Thanks for the clarification!