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
IMO ejs shouldn't allow a writable global object, and all normal JS objects should be non-writable as well, at least by default. If we disable all writes (i.e. globals are frozen) then we can inline accesses for a ton of things at compile time.
I.e.
leta=Object.create(null);
This gets transformed to contain %getGlobal(Object) (which is itself a property lookup, just with implicit obj parameter) + a normal property lookup.
If everything is frozen, then we could directly invoke the function _ejs_Object_create (not even using _ejs_invoke_closure, since we can annotate the function such that the compiler knows it doesn't close over anything.)
The text was updated successfully, but these errors were encountered:
when --frozen-global is present on the command line, it becomes a syntax error to
set a property on the global object (i.e. every lhs of an assignment has to be an
in-scope variable declaration.)
Also, since we know the global object is frozen we can inline loads from the C globals
instead of calling _ejs_global_getprop at all.
IMO ejs shouldn't allow a writable global object, and all normal JS objects should be non-writable as well, at least by default. If we disable all writes (i.e. globals are frozen) then we can inline accesses for a ton of things at compile time.
I.e.
This gets transformed to contain
%getGlobal(Object)
(which is itself a property lookup, just with implicit obj parameter) + a normal property lookup.If everything is frozen, then we could directly invoke the function
_ejs_Object_create
(not even using_ejs_invoke_closure
, since we can annotate the function such that the compiler knows it doesn't close over anything.)The text was updated successfully, but these errors were encountered: