> Does that hold anything useful?
> The next question would be, what does the engine itself do with arguments references in a generator body?
It looks like that slot is only populated if the engine decides via through static analysis that the `arguments` object will potentially be needed. That means there will be plenty of times where we pause, and we legitimately don't know what arguments were passed to the frame. I think that make sense because otherwise SpiderMonkey would be risking potential larger memory usage due to generators keeping all of their arguments live when they don't actually use them or have a way to access them.
I'm fine with leaving this feature in if we think it is useful, but I think Jason is right that we just don't have a way to consistently access the arguments after the initial execution of the frame. We should at least explicitly return `null` if you use it on a suspended frame or on a resumed on-stack frame. That would mean you can only access `frame.arguments` between the first `onEnterFrame` and `onPop`. I think the question is whether that is enough to make the feature worth having. Looking at the codebase, I only see a single usage of it, and its one that can be easily implemented another way, so that is not a blocker. It depends on whether we think it is useful from the standpoint of the `Debugger` JS API for other potential usecases, but as we've discussed, it's not easy to say whether there are other consumers of this API.
Bug 1445812 Comment 7 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
> Does that hold anything useful?
> The next question would be, what does the engine itself do with arguments references in a generator body?
It looks like that slot is only populated if the engine decides through static analysis that the `arguments` object will potentially be needed. That means there will be plenty of times where we pause, and we legitimately don't know what arguments were passed to the frame. I think that make sense because otherwise SpiderMonkey would be risking potential larger memory usage due to generators keeping all of their arguments live when they don't actually use them or have a way to access them.
I'm fine with leaving this feature in if we think it is useful, but I think Jason is right that we just don't have a way to consistently access the arguments after the initial execution of the frame. We should at least explicitly return `null` if you use it on a suspended frame or on a resumed on-stack frame. That would mean you can only access `frame.arguments` between the first `onEnterFrame` and `onPop`. I think the question is whether that is enough to make the feature worth having. Looking at the codebase, I only see a single usage of it, and its one that can be easily implemented another way, so that is not a blocker. It depends on whether we think it is useful from the standpoint of the `Debugger` JS API for other potential usecases, but as we've discussed, it's not easy to say whether there are other consumers of this API.