-
Notifications
You must be signed in to change notification settings - Fork 367
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
Babel.transform is leaking with goja #250
Comments
This is to do with WeakMaps. From the current README:
It appears that Babel is doing exactly that 😞 Good news is there is a much simpler approach to implementing WeakMaps which is also not without caveats but would work in this case. I'm going to push a change shortly. |
…sage scenarios. Fixes dop251#250.
I don't know if this is a babel issue actually, but it exists both with the very old babel we use in k6 as well as the latest one, and I can't find any issues about it so 🤷 .
The following test code
will take (roughly) twice as much memory if the
200
becomes a400
. This seems to indicate that it's leaking. This is especially obvious with the running of the tc39 tests in k6 as they take upwards of 4GB now and enabling almost all tests (most of which obviously fail) goes up to 24GB+. But if I change the code so we constantly re run (or even recompile) babel it works without going over like ... 100mb or something like that. Obviously though that makes the running time from under 20 minutes to nearly 2 hours 😭 .Looking at pprof output didn't help much except to show that stash.CreateBinding is top2 and that stash.DeleteBinding has never been called in the git history of the project. But I am not certain that matters 🤷
I would expect babel does something "normal" that ends up not being very well supported by goja. Maybe Weak* collections 🤔 , but AFAIK the k6 one works without Weak* collections, so 🤷♂️
The text was updated successfully, but these errors were encountered: