You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Evaluation of recursive records can create Rc loops, in which a thunk's environment pointer can point to an environment that itself references the thunk. This creates a memory leak, which has been observed in nls background eval.
For one-shot eval (like in nickel export) this isn't a problem, but it might be a blocker for people trying to embed nickel.
The text was updated successfully, but these errors were encountered:
One possibility would be to experiment with drop-in replacement of Rc with cycle detection, such as dumpster or a similar crates. We would have to watch the impact on performance, though. A great solution would be to be able to choose, but I don't know how easy it is, given the lack of HKT in Rust: I suspect we want to be able to be parametric in T<U> where T : * -> *, but this isn't representable. Although we have SharedTerm, ie maybe we only care about Rc<RichTerm> (and not for a generic parameter T) in which case we can abstract over it. Doing so, we could for example use the version with garbage collection for the REPL and the LSP, but keep the main evaluator performant by not dropping cyclic objects.
Evaluation of recursive records can create
Rc
loops, in which a thunk's environment pointer can point to an environment that itself references the thunk. This creates a memory leak, which has been observed in nls background eval.For one-shot eval (like in
nickel export
) this isn't a problem, but it might be a blocker for people trying to embed nickel.The text was updated successfully, but these errors were encountered: