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

Functional improvements and fixes for redeferral. #1736

Closed
wants to merge 5 commits into from

Conversation

pleath
Copy link
Contributor

@pleath pleath commented Oct 13, 2016

  1. Re-use existing FunctionBody/ParseableFunctionInfo's in the case where we re-compile a function that encloses already-compiled functions. This is necessary to avoid having multiple FunctionInfo structures around for a single FunctionBody, not all of which get updated when things change. It also reduces the cost of re-compiling. 2) Change the FunctionBody's nested function array to hold FunctionInfo's instead of FunctionProxy's. This fixes a class of functional issues involving the need to update the nested array as nested functions are un-deferred and re-deferred. The FunctionInfo pointers don't change and thus don't need updating. 3) Eliminate the m_referenceInParentFunction member of FunctionProxy, which was there to enable the nested array updates that we no longer need. 4) Re-use ScopeInfo in the case where a parent of the current function has been re-deferred.

…dalone proxy from which FunctionProxy does not inherit, and FunctionProxy is the basis for all the representations of user functions (FunctionBody, etc.). FunctionInfo still points to the FunctionProxy that implements the function, and FunctionProxy points to FunctionInfo. Do this to facilitate re-deferral and to maximize the memory benefit.
eligible for deferred parsing (e.g., not arrow functions, not
functions-in-block). This is experimental behavior, off by default. Define
an 'on' mode in which all eligible functions are redeferred on GC, as well
as a 'stress' mode in which all candidates are redeferred on each stack
probe. This change is built on a previous PR that refactors the
FunctionBody hierarchy to make it easier to toggle between deferred and
fully-compiled states.
…k that Rajat did a while back. The heuristic uses 5 constants: an initial delay, which is the number of GC's we perform before we start checking for redeferral candidates; the number of GC's to wait between redeferral checks while we're in the startup phase; the number of GC's that must have passed since a function was executed before we redefer it in the startup phase; and the same wait and inactivity constants for the main phase, to which we transition after the startup phase ends. Todo: emit jitted code to reset a function's inactivity count when the function is executed, and/or avoid redeferring a jitted function if we think it may be executed again.
…FunctionBody/ParseableFunctionInfo's in the case where we re-compile a function that encloses already-compiled functions. This is necessary to avoid having multiple FunctionInfo structures around for a single FunctionBody, not all of which get updated when things change. It also reduces the cost of re-compiling. 2) Change the FunctionBody's nested function array to hold FunctionInfo's instead of FunctionProxy's. This fixes a class of functional issues involving the need to update the nested array as nested functions are un-deferred and re-deferred. The FunctionInfo pointers don't change and thus don't need updating. 3) Eliminate the m_referenceInParentFunction member of FunctionProxy, which was there to enable the nested array updates that we no longer need. 4) Re-use ScopeInfo in the case where a parent of the current function has been re-deferred.
@pleath
Copy link
Contributor Author

pleath commented Oct 22, 2016

Out-of-date PR, incorporated into #1585.

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

Successfully merging this pull request may close these issues.

2 participants