4 ms·

> only a side effect of the standard hidden class optimization, not because there was intention of having a certain order Do you have a reference for this? I c

by gsg 12y ago

> only a side effect of the standard hidden class optimization, not because there was intention of having a certain order Do you have a reference for this? I clearly recall a Lars Bak interview in which he says that adding a property .x and then .y results in an object of different hidden class than adding .y and then .x exactly because people want to rely on iteration order. (Might not apply to numeric keys, though.)

esailija 12y ago
It results in different hidden class because the whole point is to be able to reference named fields by fixed offsets from the object location in memory (same as for example reading struct fields in C). If the order changes, so will the offsets too, so same names with different order must have different hidden classes. Integer keys are not practical to treat as fixed because they are used as array indices 99% of the time which are dynamic. So they should be optimized differently, and they are. They are backed by a dynamically resized array (so it's implemented like Java's ArrayList). And it's not possible to track insertion order in this representation, so integer keys have different iteration order from named keys. Note that doing hash-tabley things with the objects (like changing their property order constantly, deleting named keys and so on) will change the backing representation to ordered hash table. The ordered hash table emulates the same order that results from the nature of the above optimizations to make it less surprising for user when the representation changes. If it wasn't ordered, it would be very surprising when the iteration order suddenly changed from ascending integer keys and insertion ordered named keys to something completely random.
- gsg 12y ago
 I don't think your explanation makes much sense. Hidden classes describe the layout of objects: if two insertion orders produced the same hidden class, it would mean they have the same layout, with the same fixed field offsets. The only difficulty I can see with doing that is that is insertion order.
 - esailija 12y ago
 I am not sure what you are even saying. My point is that if the most optimal way would result in some other iteration order, that would be the iteration order experienced by users and that it is just a coincidence that the most optimal way results in insertion order.
 - gsg 12y ago
 I'm saying that argument is wrong, because there is no efficiency loss due to different insertion orders mapping to the same hidden class. In fact there are efficiency advantages because more objects would pass through class-based guard checks into favourable paths. The only reason I can see to not do that is because it would lose iteration order. Sketch out an example of hidden class transitions and it should be clear: In the order preserved case (what JS engines actually do): start with {} of hidden class <empty> add .x, transition to hidden class <A> with field .x at 0 add .y, transition to hidden class with field .x at 0 and field .y at 1 start with {} of hidden class <empty> add .y, transition to hidden class <C> with field .y at 0 add .x, transition to hidden class <D> with field .y at 0 and field .x at 1 In the order discarded case: start with {} of hidden class <empty> add .x, transition to hidden class <A> with field .x at 0 add .y, transition to hidden class with field .x at 0 and field .y at 1 start with {} of hidden class <empty> add .y, transition to hidden class <C> with field .y at 0 add .x, transition to hidden class with field .x at 0 and field .y at 1 In the second case the field .y changes offset, but that's fine because the hidden class also changes to indicate the difference in structure. The only problem is that the order of the fields changes.
 - Arnavion 12y ago
 By the way, JS runtimes used to have insertion order for enumerating properties long before the hidden class optimization or V8 was a thing. V8 was the first to break the insertion-order enumeration for some kinds of objects [1] and eventually other browsers followed suit, even those that don't do hidden classes. [1] http://code.google.com/p/v8/issues/detail?id=164 http://code.google.com/p/v8/issues/detail?id=164
gsnedders 12y ago
Yes, the requirement to preserve order predates V8 by years (I believe all the way back to SpiderMonkey, though maybe it was JScript?). Certainly it's long been the case the web de-facto relies on insertion order being preserved (except V8 found that it didn't really for numeric keys, where there was far more variety between implementations, and Carakan and Chakra followed by similarly dropping order for numeric keys).

by gsg 12y ago

esailija 12y ago

It results in different hidden class because the whole point is to be able to reference named fields by fixed offsets from the object location in memory (same as for example reading struct fields in C). If the order changes, so will the offsets too, so same names with different order must have different hidden classes. Integer keys are not practical to treat as fixed because they are used as array indices 99% of the time which are dynamic. So they should be optimized differently, and they are. They are backed by a dynamically resized array (so it's implemented like Java's ArrayList). And it's not possible to track insertion order in this representation, so integer keys have different iteration order from named keys. Note that doing hash-tabley things with the objects (like changing their property order constantly, deleting named keys and so on) will change the backing representation to ordered hash table. The ordered hash table emulates the same order that results from the nature of the above optimizations to make it less surprising for user when the representation changes. If it wasn't ordered, it would be very surprising when the iteration order suddenly changed from ascending integer keys and insertion ordered named keys to something completely random.

gsg 12y ago
I don't think your explanation makes much sense. Hidden classes describe the layout of objects: if two insertion orders produced the same hidden class, it would mean they have the same layout, with the same fixed field offsets. The only difficulty I can see with doing that is that is insertion order.
- esailija 12y ago
 I am not sure what you are even saying. My point is that if the most optimal way would result in some other iteration order, that would be the iteration order experienced by users and that it is just a coincidence that the most optimal way results in insertion order.
 - gsg 12y ago
 I'm saying that argument is wrong, because there is no efficiency loss due to different insertion orders mapping to the same hidden class. In fact there are efficiency advantages because more objects would pass through class-based guard checks into favourable paths. The only reason I can see to not do that is because it would lose iteration order. Sketch out an example of hidden class transitions and it should be clear: In the order preserved case (what JS engines actually do): start with {} of hidden class <empty> add .x, transition to hidden class <A> with field .x at 0 add .y, transition to hidden class with field .x at 0 and field .y at 1 start with {} of hidden class <empty> add .y, transition to hidden class <C> with field .y at 0 add .x, transition to hidden class <D> with field .y at 0 and field .x at 1 In the order discarded case: start with {} of hidden class <empty> add .x, transition to hidden class <A> with field .x at 0 add .y, transition to hidden class with field .x at 0 and field .y at 1 start with {} of hidden class <empty> add .y, transition to hidden class <C> with field .y at 0 add .x, transition to hidden class with field .x at 0 and field .y at 1 In the second case the field .y changes offset, but that's fine because the hidden class also changes to indicate the difference in structure. The only problem is that the order of the fields changes.
 - Arnavion 12y ago
 By the way, JS runtimes used to have insertion order for enumerating properties long before the hidden class optimization or V8 was a thing. V8 was the first to break the insertion-order enumeration for some kinds of objects [1] and eventually other browsers followed suit, even those that don't do hidden classes. [1] http://code.google.com/p/v8/issues/detail?id=164 http://code.google.com/p/v8/issues/detail?id=164

gsnedders 12y ago

Yes, the requirement to preserve order predates V8 by years (I believe all the way back to SpiderMonkey, though maybe it was JScript?). Certainly it's long been the case the web de-facto relies on insertion order being preserved (except V8 found that it didn't really for numeric keys, where there was far more variety between implementations, and Carakan and Chakra followed by similarly dropping order for numeric keys).