-
-
Notifications
You must be signed in to change notification settings - Fork 400
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
Implement Tail Call Optimization #3510
base: main
Are you sure you want to change the base?
Conversation
Test262 conformance changes
Fixed tests (21):
|
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #3510 +/- ##
==========================================
+ Coverage 49.01% 49.05% +0.03%
==========================================
Files 469 469
Lines 48186 48245 +59
==========================================
+ Hits 23618 23666 +48
- Misses 24568 24579 +11 ☔ View full report in Codecov by Sentry. |
The implementation looks pretty straight forward. I like it. @RageKnify do you know the more detailed reasons why V8 droped it as a maintanance burden? With our current VM it seems to work pretty well right? @HalidOdat do you think there could be future issues with this? I would be in favor of merging this. If it becomes hard to maintain or blocks features in the future we could always remove for the same reason V8 did it. |
I'm in favour of merging this, but only if we add a way to disable the optimization. I'm mostly worried about our recursion limit, which could be bypassed by this feature. Bonus points if we document this on the recursion limit setter/getter EDIT: alternatively, if we want to always do the optimization, we could consider it as a "pseudo-loop", and make it count for the loop limit, but I'm not sure how feasible that would be with indirect recursion. EDIT2: Found a source about how JSC preserves stack traces with PTC using a shadow stack (see "Debugging PTC with ShadowChicken") https://webkit.org/blog/6240/ecmascript-6-proper-tail-calls-in-webkit/ |
I like this idea. If we can make that work that would be my prefered solution. |
Correct stack traces is the biggest concern (which @jedel1043 proposed a solution). I would prefer either waiting for the stack trace or we implement the JSC shadow stack (In this PR or a follow up PR) since if we implement stack traces we will have implement it anyway.
It should be easy since we have access to the previous frame that is popped and we just increment and check. NOTE: In general I would prefer the users use the budget functions to restrict the compute, how i see it is the recursion limit is more of a call frame limit, and tail call does not add any frames. |
This Pull Request implements Tail Call Optimization as described in the spec: tail-position-calls
It changes the following:
TailCall
that can is compatible withCall
and will performTCO
if possibleByteCompiler::optimize
that introduces optimizations to the bytecode codeWhile the spec says that TCO should be implemented most engines do not currently support it. Apple's JavaScriptCore is the only mainstream implementation as far as I am aware. When it was first introduced V8 implemented it but after Firefox and Internet Explorer pushed back and it was clear not all browsers would have it V8 dropped it to avoid maintaining unnecessary code.
Given that I wanted to get all of @boa-dev/maintainers opinions on implementing these parts of the spec that aren't technically required. I did it mostly as a challenge since it is a topic I find interesting so I understand if the choice is to not incorporate the code.