Bug 1709542 Comment 2 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

So the story at this point: In Bug 1662559, Jason Orendorff and I changed the storage mechanism for private methods in order reduce the storage requirements of methods. Before that patch stack, each object with a private method was required to have slot for that method. So, 

``` 
class A { 
  #x() { return 1; 
} 
var a = new Array(1000).fill(1).map(() => new A); 
```
would have each instance of A have a slot dedicated holding `#x`, consuming `1000 * slotSize` of memory. 

After those patches, instead, there is only one slot, held in the environment object corresponding to `class A`, which holds the reference to `#x`. 

The problem is: Our current front end drops too much information, and is unable to reconstruct the correct location of `#x` in debugger frames. 

This is surmountable, but I didn't consider it a blocker to landing the implementation of fields/methods. 

I will spend some time this week trying to figure out the cost of hanging on to enough information to correctly make this work. As those comments hint at; we have *most of the machinery required* already, but there are few obstacles that remain.
So the story at this point: In Bug 1662559, Jason Orendorff and I changed the storage mechanism for private methods in order reduce the storage requirements of methods. Before that patch stack, each object with a private method was required to have slot for that method. So, 

``` 
class A { 
  #x() { return 1; }
} 
var a = new Array(1000).fill(1).map(() => new A); 
```
would have each instance of A have a slot dedicated holding `#x`, consuming `1000 * slotSize` of memory. 

After those patches, instead, there is only one slot, held in the environment object corresponding to `class A`, which holds the reference to `#x`. 

The problem is: Our current front end drops too much information, and is unable to reconstruct the correct location of `#x` in debugger frames. 

This is surmountable, but I didn't consider it a blocker to landing the implementation of fields/methods. 

I will spend some time this week trying to figure out the cost of hanging on to enough information to correctly make this work. As those comments hint at; we have *most of the machinery required* already, but there are few obstacles that remain.

Back to Bug 1709542 Comment 2