Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Memory leak with long-running nickel process #1908

Open
jneem opened this issue May 3, 2024 · 1 comment
Open

Memory leak with long-running nickel process #1908

jneem opened this issue May 3, 2024 · 1 comment

Comments

@jneem
Copy link
Member

jneem commented May 3, 2024

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.

@jneem jneem added the type: bug label May 3, 2024
@yannham
Copy link
Member

yannham commented May 4, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants