Revise redeferral heuristic #1786
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…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.
…ns without generating new code. We make use of the per-entry-point calls count for jitted entry points as well as the interpreted count for the FunctionBody.
|
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
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Revise redeferral heuristic to track execution of full-jitted functions without generating new code. We make use of the per-entry-point calls count for jitted entry points as well as the interpreted count for the FunctionBody. Incorporates the jitted code changes to stop saturating the callsCount field.