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
