-
Benedikt Meurer authored
Change the way that the (internal) await closures store the link to the generator object by introducing a dedicated AwaitContext, which stores the generator object into the extension slot (instead of misusing a regular FunctionContext here). Also unify the allocation+initialization of these contexts in the await-related builtins (both for async functions and generators). The rationale behind this is that for (zero-cost) async stack traces, we will need to dig into these contexts and we can do better checking with a dedicated instance type there. As an additional benefit, we save one word per await context, since we just use (the otherwise unused) extension slot to remember the generator object. As yet another benefit we will never accidentally use any of these contexts in the regular scope chain lookups, meaning we can also catch bugs there. And last but not least the objects printing machinery understands these contexts now and can even print the generator object for AwaitContexts for short printing, which is really valuable for debugging. Tbr: ulan@chromium.org Bug: v8:7253, v8:7522, v8:8015 Change-Id: I86955f5701e694e8a10b91ebe5f52705aa90968d Reviewed-on: https://chromium-review.googlesource.com/1249491Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#56301}
9e99297e