3 ms·

I see the 'stricter' mode (without types) as a kind of asm.js assertion. The code is 100% legal JS and will work on all JS VMs, you're just telling the VM that

I see the 'stricter' mode (without types) as a kind of asm.js assertion. The code is 100% legal JS and will work on all JS VMs, you're just telling the VM that it can assume you won't modify class prototypes after load. The VM can check this assertion and fail if you violate it, and then run at fulls peed. On other VMs that ignore "use 'stricter'" the same code runs, just less optimized by the VM. The stricter+types stuff will be harder to swallow by the community since it extends the language grammar. That will break other VMs without transpilation. Maybe they could do a "use 'stricter+asm'" which has the class-sealing properties SoundScript, but with the type-declaration syntax of asm.js (|0, 0, etc)

azakai 12y ago
I'm still unclear on the relevant details, though. If this is just a hint - no semantic effect - then JS engines already speculate and assume you won't modify class prototypes after load. Such speculation is what JS engines put a lot of work into. Maybe the hint would justify more aggressive speculation, I suppose? Or, if this is more than a hint - if it has semantic effects, like "use strict" does - then this would be very different than "use asm". I guess when more info comes out this will become clearer.
- cromwellian 12y ago
  I'm guessing that it implicitly implies Object.seal() on all prototypes. Any legal program that uses 'stricter' and depends on sealed prototypes would be a legal program on a VM that ignores stricter, except in the case of bugs where code was modifying prototypes when it shouldn't, but those would presumably be caught during testing on VMs which did use it. Presumably, "use stricter" on a codebase that contained attempted prototype modifications would generate errors instead of silent failures. I don't know the full reasoning behind this, but it might be more about startup time than runtime speed. If you assume early-bound classes, snapshotting becomes a lot easier, you can ahead-of-time trivially compile hidden classes without having to discover them after the fact, and without having to put in code to revert the assumptions later. Seems like this would be a startup and memory win mobile web, especially if you can easily snapshot a previously loaded app.
mraleph 12y ago
Sealing prototypes is easy - V8 already "pseudo"seals them: it removes the map checks against prototypes and instead deoptimizes the code depending on hidden classes when somebody changes them. Similar pseudo-sealing technique can be applied to objects: when optimizing some code you can assume that if some hidden class is a leaf in the transition tree it is no likely to change - then make the code depend on this assumption. This would mean you only need to check this once. I think the most interesting part that stricter-minus-types mode brings to the table (at least it's informally described part) are hole-less arrays. This is something that is missing from the ES as it is described now: new Array(N) is producing a hole-full array. V8 is capable of tracking whether array is containing holes or not - but the way to efficiently preallocate holeless version is simply missing from the ECMAScript.

azakai 12y ago

I'm still unclear on the relevant details, though. If this is just a hint - no semantic effect - then JS engines already speculate and assume you won't modify class prototypes after load. Such speculation is what JS engines put a lot of work into. Maybe the hint would justify more aggressive speculation, I suppose? Or, if this is more than a hint - if it has semantic effects, like "use strict" does - then this would be very different than "use asm". I guess when more info comes out this will become clearer.

cromwellian 12y ago
I'm guessing that it implicitly implies Object.seal() on all prototypes. Any legal program that uses 'stricter' and depends on sealed prototypes would be a legal program on a VM that ignores stricter, except in the case of bugs where code was modifying prototypes when it shouldn't, but those would presumably be caught during testing on VMs which did use it. Presumably, "use stricter" on a codebase that contained attempted prototype modifications would generate errors instead of silent failures. I don't know the full reasoning behind this, but it might be more about startup time than runtime speed. If you assume early-bound classes, snapshotting becomes a lot easier, you can ahead-of-time trivially compile hidden classes without having to discover them after the fact, and without having to put in code to revert the assumptions later. Seems like this would be a startup and memory win mobile web, especially if you can easily snapshot a previously loaded app.

mraleph 12y ago

Sealing prototypes is easy - V8 already "pseudo"seals them: it removes the map checks against prototypes and instead deoptimizes the code depending on hidden classes when somebody changes them. Similar pseudo-sealing technique can be applied to objects: when optimizing some code you can assume that if some hidden class is a leaf in the transition tree it is no likely to change - then make the code depend on this assumption. This would mean you only need to check this once. I think the most interesting part that stricter-minus-types mode brings to the table (at least it's informally described part) are hole-less arrays. This is something that is missing from the ES as it is described now: new Array(N) is producing a hole-full array. V8 is capable of tracking whether array is containing holes or not - but the way to efficiently preallocate holeless version is simply missing from the ECMAScript.