Hmm interesting.. I would think that kind of pattern comes up frequently. Although I didn't know the optimizer could inline polymorphic classes like that.
On Sat, Dec 17, 2011 at 6:33 PM, Vyacheslav Egorov <[email protected]>wrote: > Yes, new Thing(true) and new Thing(false) will produce objects with > different hidden-classes (though all new Thing(x) for a fixed x will have > the same hidden class). > > Sites that see both kinds Things will go megamorphic (become slower than > monomorphic, yet faster than just going to runtime). Optimizer will try to > deal with polymorphism by inlining (limited amount) of polymorphic cases. > > -- > Vyacheslav Egorov > > > On Sat, Dec 17, 2011 at 8:51 PM, Marcel Laverdet <[email protected]>wrote: > >> I only have a loose understanding of v8's hidden classes and optimizer, >> but there's something I've always wondered about hidden classes that I >> figured I could hijack this thread for.. >> >> How do hidden classes handle this case? >> >> function Thing(switch) { >> if (switch) { >> this.whatever = true; >> } >> ... >> } >> >> From what I understand (basically just watching those videos of Lars Bak >> talk about v8 internals) it seems in this case, instances of Thing would >> have divergent hidden classes right from the very start. This would then >> ripple out into the optimizer leading to code that couldn't be optimized >> with fast property access. >> >> It seems like this would be a fairly common case.. is there something I'm >> missing that makes this not as bad as it seems? >> >> >> On Sat, Dec 17, 2011 at 10:19 AM, Vyacheslav Egorov <[email protected] >> > wrote: >> >>> It should be noted that hidden classes have at least two advantages: >>> >>> 1) they go beyond simple index to property mappings and can capture many >>> different aspects (types of backing stores, constant function properties, >>> type specific optimized construction stubs, estimated number of properties >>> that will be added to an object). >>> >>> 2) allow to optimize memory usage --- dictionary based backing stores a >>> much less compact. >>> >>> Your suggestion of course is viable (and well known, >>> e.g. similar approach is used for example by LuaJIT2) optimization that can >>> be used to make monomorphic dictionary lookups faster. >>> >>> However it cannot replace hidden classes entirely as noted above. >>> >>> -- >>> Vyacheslav Egorov >>> >>> >>> On Sat, Dec 17, 2011 at 11:31 AM, Vladimir Nesterovsky < >>> [email protected]> wrote: >>> >>>> Yesterday I've seen an article about some design principles of V8 >>>> JavaScript Engine (http://code.google.com/apis/v8/design.html). In >>>> particular V8 engine optimizes property access using "dynamically >>>> created hidden classes", they are derived when a new property is >>>> created (deleted) on the object. >>>> >>>> We would like to suggest a slightly different strategy, which exploits >>>> the cache matches, and does not require a dynamic hidden classes. >>>> >>>> Consider an implementation data type with following characteristics: >>>> >>>> a) object is implemented as a hash map of property id to property >>>> value: Map<ID, Value>; >>>> b) it stores data as an array of pairs and can be accessed directly: >>>> Pair<ID, Value> values[]; >>>> c) property index can be acquired with a method: int index(ID); >>>> >>>> A pseudo code for the property access looks like this: >>>> >>>> pair = object.values[cachedIndex]; >>>> >>>> if (pair.ID == propertyID) >>>> { >>>> value = pair.Value; >>>> } >>>> else >>>> { >>>> // Cache miss. >>>> cachedIndex = object.index(propertyID); >>>> value = objec.values[cachedIndex].Value; >>>> } >>>> >>>> This approach brings us back to dictionary like implementation but >>>> with important optimization of array speed access when property index >>>> is cached, and with no dynamic hidden classes. >>>> >>>> See also >>>> http://www.nesterovsky-bros.com/weblog/2011/12/17/FastPropertyAccessInV8JavaScriptEngine.aspx >>>> -- >>>> Vladimir Nesterovsky >>>> >>>> -- >>>> v8-users mailing list >>>> [email protected] >>>> http://groups.google.com/group/v8-users >>>> >>> >>> -- >>> v8-users mailing list >>> [email protected] >>> http://groups.google.com/group/v8-users >>> >> >> -- >> v8-users mailing list >> [email protected] >> http://groups.google.com/group/v8-users >> > > -- > v8-users mailing list > [email protected] > http://groups.google.com/group/v8-users > -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
