6 Jun
2023
6 Jun
'23
6:46 p.m.
On Tue Jun 6 18:36:43 2023 +0000, **** wrote:
Gabriel Ivăncescu replied on the mailing list:
On 06/06/2023 19:49, Gabriel Ivăncescu (@insn) wrote: > On Tue Jun 6 15:38:45 2023 +0000, Jacek Caban wrote: >> I'm not sure that an improvement (and at very least could be a separated >> patch). Note that we expect vast majority of arguments objects to never >> need this buffer. > Oh, I did it that way because it was simpler, since I always allocated the buffer in `setup_arguments_object` unconditionally. That's because it's used a lot more with this patch (for all argument lookups that aren't on the stack). Before, it was used only when the frame was detached. > > Should I try to allocate it on demand? Note that detaching the variable obj will make use of it now (so it will allocate it). > Nevermind, I found a subtle problem. We'll need **two** buffers. The original buffer has to be used when the arguments object is detached from execution context. The new buffer I added was just to store the detached variable obj props that would otherwise go into the variable object, except that it works for duplicated arg names (shadowed). This buffer should be allocated unconditionally, so I'll use variable length to avoid two allocations and complicating the setup. Both buffers will be needed: the original buf for detached arguments object, and the new buf to hold the parameters for detached variable obj.
It may be interesting to try to store all locals in a buffer and eliminate variable object for most cases.