+adamk On Fri, Dec 21, 2012 at 3:05 PM, Vyacheslav Egorov <[email protected]>wrote:
> 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
