Ran into the use case for this feature when helping Boris look into an issue of why LICM wasn't lifting a GetProp out of a loop. Turned out the loop contained a |call|, and the GetProp depended on a shape guard of a constant prototype object, and the shape guard was aliased by the call. This reveals a general optimization problem: Typically, objects with singleton types (such as prototype objects, etc).. don't change after they are initially "filled" with their bindings. However, we are often forced to guard on their shapes to retrieve various values. In the above case, this guarding not only has a runtime cost, but prevents the lifting of an otherwise liftable property-get. We should explore extending the engine to allow adding an invalidation hook to singleton types which will fire when the corresponding object's lastProperty changes. Objects with these watches will be forced to have a non-lazy type, but that's not a huge deal, because only jit-optimized prototypes will be forced to keep their type-objects non-lazy. If we need to force the object to have a lazy type again, we can always fire the hook and invalidate all scripts that depend on it. Extending this scenario, we can also hypothesize that the data-slots of a singleton object don't change very often. There may be value in extending this concept to allow scripts to inline values in the object's data slots, and attach invalidation hooks which will get fired when the data slots suffer mutation.

Brian: what do you think of the above suggestion? Is it doable? Any catch I'm missing?

Yeah, this is doable. Hannes is interested in similar stuff IIRC, especially the last paragraph and ability to freeze the contents of arbitrary properties from the compiler's point of view.

(In reply to Brian Hackett (:bhackett) from comment #2) > Yeah, this is doable. Hannes is interested in similar stuff IIRC, > especially the last paragraph and ability to freeze the contents of > arbitrary properties from the compiler's point of view. Yeah that would definitely help me. It would be a 4% win on richards if this was implemented and I could add those constraints for constants based on shapeguards. But I think you saw that bug Kannan, right?

(In reply to Kannan Vijayan [:djvj] from comment #0) > Ran into the use case for this feature when helping Boris look into an issue > of why LICM wasn't lifting a GetProp out of a loop. Turned out the loop > contained a |call|, and the GetProp depended on a shape guard of a constant > prototype object, and the shape guard was aliased by the call. I have planned to address similar issues as part of the work I do on my spare time to enable escape analysis in IonMonkey. If objects with singleton types are not changing, then we do not need to go as far as escape analysis and we should be able to work on top of the refactoring of alias analysis (Bug 897606) that I am doing right now. In a few days (by Monday hopefully), I would have enough abstraction to declare a new kind of Alias identifier which should be able to isolate alias sets based on their type sets. Note that one of the issue would be to prevent that 2 objects with singleton types do not alias each others, and only having a category like we do have at the moment as part of the AliasSet is not enough to distinguish without adding more special cases.