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

Replace purgeModule cache busting with vm based sandboxing #660

Merged
merged 1 commit into from
Feb 26, 2021

Conversation

rwjblue
Copy link
Member

@rwjblue rwjblue commented Feb 25, 2021

The template compiler contents have to be evaluated separately for each addon in the build pipeline. If they are not the AST plugins from one addon leak through to other addons (or the app).

This issue led us to attempt to purge the normal node require cache (the purgeModule code). This works (and has been in use for quite a while) but causes a non-trivial amount of memory overhead since each of the addons' ends up with a separate template compiler. This prevents JIT'ing and it causes the source code of the template compiler itself to be in memory many many many times (non-trivially increasing memory pressure).

Migrating to vm.Script and sandboxed contexts (similar to what is done in FastBoot) resolves both of those issues. The script itself is cached and not reevaluated each time (removing the memory pressure issues) and the JIT information of the script context is also shared.

Thanks to @krisselden for pointing out this improvement!

@rwjblue rwjblue force-pushed the cache-template-compiler-evaluation branch from 70225e8 to 5536c6e Compare February 26, 2021 00:11
The template compiler contents have to be evaluated separately for each
addon in the build pipeline. If they are **not** the AST plugins from
one addon leak through to other addons (or the app).

This issue led us to attempt to purge the normal node require cache (the
`purgeModule` code). This works (and has been in use for quite a while)
but causes a non-trivial amount of memory overhead since each of the addons'
ends up with a separate template compiler. This prevents JIT'ing and it
causes the source code of the template compiler itself to be in memory
many many many times (non-trivially increasing memory pressure).

Migrating to `vm.Script` and sandboxed contexts (similar to what is done
in FastBoot) resolves both of those issues. The script itself is cached
and not reevaluated each time (removing the memory pressure issues) and
the JIT information of the script context is also shared.

Thanks to @krisselden for pointing out this improvement!
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants