Hey Kevin! Thanks for your comments. They are really helpful for me to further understand the current type-feedback mechanisms in V8. I am still missing parts of the picture, so please bear with me.
On Thu, Dec 8, 2011 at 12:15, <[email protected]> wrote: > > This treats function-valued object properties, when called as > constructors, as > methods of the object holding them. I don't think that's quite right and > I can > see problems down the line. > I think that's exactly what they are. IMHO, constructors are methods of the object holding them. That object might be a real object (as in the case of raytrace.js) or some global object. The constructor just gets a newly created object passed as the 'this' value. But again, I am missing the big picture to see the problems down the line. It misses the common use of constructors which are not properties of any > object. > We will want to optimize that case, and I don't think we want two > different > mechanisms. > Yes, it doesn't yet cover constructors which are not properties of any (non-global) object. And I agree that we need to optimize those too. But for raytrace.js (and everything else that uses the Prototype framework or something similar), that is actually not the common case. There almost all constructors are properties of objects used as namespaces or classes. > Another downside of this approach is that we only know the function > identity > from the map for CONSTANT_FUNCTION, not FIELD. I think we'll want to > optimize > the field case, too. > > Maybe a better approach is to record monomorphic constructor function > identity > at the call site, like we do with the CallFunctionStub. > Will this approach alone (without additional ICs) be enough to record all necessary type information for JavaScript based on the Prototype framework? Let me try to follow your train of thought here: We could use GlobalPropertyCells referenced at the call site which will hold references to JSFunction objects at monomorphic call sites. That way the function lookup is basically handled by a previous LoadIC (or however the function is loaded). That sounds like a simpler approach! I like it a lot (if it can gather the same class of type feedback). > (As an aside, we will have to change our handling of CallIC sometime in > order to > support the ES5 semantics. When we do that, and with this change, we will > either end up with the wrong semantics for these constructors, or else two > modes > of CallICs, or else a new infrastructure for method calls and keeping all > the > old CallIC code around just to support this case.) > I still don't see the difference in that regard between [[Call]] and [[Construct]]. All differences between those two invocations are taken care of by the construct stub. All other aspects should be the same for both. Best regards, Michael -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev
