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 <mar...@laverdet.com>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
> <vego...@chromium.org>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 <
>> vladi...@nesterovsky-bros.com> 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
>>> v8-users@googlegroups.com
>>> http://groups.google.com/group/v8-users
>>>
>>
>> --
>> v8-users mailing list
>> v8-users@googlegroups.com
>> http://groups.google.com/group/v8-users
>>
>
> --
> v8-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users
>
--
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
