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

Add support for globalLexicals #35

Open
kriskowal opened this issue Oct 28, 2020 · 1 comment
Open

Add support for globalLexicals #35

kriskowal opened this issue Oct 28, 2020 · 1 comment

Comments

@kriskowal
Copy link
Member

The motivation for this change is for metering, which is related to coverage analysis instrumentation.

In coverage analysis instrumentation, compartments need:

  1. a global that can capture coverage information
  2. a transform that converts every expression into an equivalent expression that also notes coverage information.

For example, the expression value would be transformed to (coverage._x0fd++, value), where the arbitrary key _x0fd uniquely identifies the expression.

For coverage analysis, we might not be worried about user code “attacking” their coverage analysis, so adding coverage to globalThis is sufficient. However, user code could alter its coverage results by including the statement coverage._x0fd = 1e10, for example.

The coverage tooling can censor the word coverage, throwing an exception if the user code includes this word anywhere. This would even frustrate user code that attempted to reach for coverage through computing an evaluated string, likee (0, eval("cov" + "er" + "age")), because within the compartment, the argument to eval is itself user code subject to all the compartment’s transforms.

This is not sufficient because user code can still compute properties of globalThis, like globalThis["cov" + "er" + "age"]. A transform that virtualizes all computed properties would be impractically slow. So, instead, we propose that the Compartment constructor accept a globalLexicals option. The global lexicals would exist in a scope that overshadows globalThis but cannot be named in that scope. By using globalLexicals instead of globalThis, banning the word “coverage” is sufficient to prevent user code from manipulating this special register.

The compartment constructor must capture a snapshot of the given global lexicals and present these as constants in the scope of all modules and all evaluated code. Changes to the given global lexicals should not be observable. An accessor property on a global lexical must be called exactly once in the scope of the constructor.

This proposal bears a resemblance to the concept hitherto named “global contour” #34. Ideally global lexicals and the global contour could be reconciled into a single feature, though that requires reconciling the immutability of global lexicals with the mutability of the global contour, and that the global contour must be manipulated by evaluated code should not be observable in modules.

@Jack-Works
Copy link
Member

Does it mean when lookup a reference, it will go through this order?

globalThis < (not accessible ) globalLexicals < local scope

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

No branches or pull requests

2 participants