Some high level observations: Adding a property changes hidden class but does not change how elements look like because they are stored independently.
[V8 Crypto for example has arrays carrying around properties, and I am pretty sure the same happens in the other real world code] Now imagine a completely generic array code, like the one in array builtins, it does not make sense to make it polymorphic with respect to hidden classes at every site which accesses array element because the only thing that matters is the way elements are represented. On Dec 21, 2012 9:33 PM, "Adam Klein" <[email protected]> wrote: > > On Fri, Dec 21, 2012 at 2:56 AM, Andreas Rossberg <[email protected]> wrote: >> >> On 20 December 2012 23:51, Rafael Weinstein <[email protected]> wrote: >>> >>> On Tue, Dec 11, 2012 at 5:42 AM, <[email protected]> wrote: >>>> >>>> Description: >>>> Object.observe: prevent observed objects from using fast elements. >>>> >>>> This is necessary because polymorphic stores generally >>>> do not perform a map check but only an instance type check, >>>> which misses out on changes in the observation status. >>>> Unfortunately, there currently is no efficient way in V8 >>>> to maintain that optimisation in the presence of Object.observe. >>> >>> >>> Out of curiosity, how expensive would the additional map check be? I.e. how much would it regress relevant benchmarks? >> >> >> The cost isn't so much the map check itself, but the fact that a failed map check would deopt (and introduce more polymorphic sites). Only checking the elements kind makes sure that any access to indexed properties (i.e., especially arrays) is completely oblivious to differences in other aspects of the objects it sees. Apparently, that scheme was introduced because it was relevant for benchmarks. I don't have any concrete numbers, though. > > > I'd be interested in finding out which benchmark(s) depend on this behavior, since it seems pretty weird to me for an array to go through map transitions (unless adding an element causing a transition?). > >> >> The only way we saw to maintain this scheme would be by duplicating the observation status in the elements kind. But given the already highly complex lattice of elements kinds, and the number of specialised code paths it implies, our array experts scared stiff in terror at the mere idea. > > > I understand why we wouldn't want to add more elements kinds. Something Rafael and I aren't clear on is why the "observed" bit has to go there. Is there no where else available where we could efficiently check this? (I feel like I could really use a diagram of memory layout of objects + maps to better understand the constraints here.) > > - Adam > > -- > v8-dev mailing list > [email protected] > http://groups.google.com/group/v8-dev -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev
