On Tue, Nov 4, 2014 at 12:25 PM, Dmitry Lomov <[email protected]> wrote:
> > > On Tue, Nov 4, 2014 at 11:56 AM, 'Andreas Rossberg' via v8-users < > [email protected]> wrote: > >> On 4 November 2014 10:16, Dmitry Lomov <[email protected]> wrote: >> > On Tue, Nov 4, 2014 at 8:43 AM, 'Andreas Rossberg' via v8-users >> > <[email protected]> wrote: >> >> >> >> On 3 November 2014 16:58, Andreas Rossberg <[email protected]> >> wrote: >> >> > On 3 November 2014 16:47, Caitlin Potter <[email protected]> >> wrote: >> >> >> It looks like there is machinery in `Scope` for storing internal >> >> >> variables. >> >> >> Could we not grant each tagged template a custom ID, in order for >> it to >> >> >> look >> >> >> up the appropriate callSiteObj in scope, and store a new internal >> value >> >> >> there if one does not already exist? >> >> > >> >> > Sounds good to me. That way, we can desugar it in the parser, which >> is >> >> > always best. >> >> >> >> On re-reading the spec, that doesn't work. A local variable would only >> >> cache the callSite object per surrounding function invocation, not >> >> globally. The SharedFunctionInfo doesn't work either, because of code >> >> caching/sharing. We really need to associate the object with the >> >> script identity, but I don't think we have an easy way of doing so. >> > >> > Correct, that is the main issue here (spec is very unhelpful, >> associating >> > call site to "source code" - what does it even mean?) >> >> It also indexes them by "productions", which is even more meaningless >> (I already filed a bug about the misuse of the notion of "production" >> all throughout the spec, but I doubt it will be fixed). >> >> > The correct cache seems to be something along the lines of >> > (native context, script source, postion) => call site >> > >> > CallSites are (global) context specific of course, that's why we have >> native >> > context on lhs of this relation. >> > My suggestion would be hanging map of [(hash(script source), position) >> => >> > call side] off native context. >> >> That's not good enough -- there may be multiple equal scripts executed >> within the same realm, especially using eval. They still need to map >> to separate call site objects. > > > I do not believe they should map to separate call sites. > The spec says "associated with the source code" which does not mean > anything and callsites are frozen so no harm can happen. > (caching in global context would also work of course but will require some tracking from the parser at least - not sure what's best yet) > >> That's why I suggested something per >> _global_ context (which is per script). A mapping like >> >> (global context, script source, position) => call site >> >> would work, presuming we create a global context whenever a script >> contains a template literal somewhere (even if the context is >> otherwise empty). >> >> > I haven't thought through all the implications though (this map has to >> be >> > cleared some time etc) >> >> Why would it need clearing? It won't be large anyway, and it seems >> fine to keep it alive with the associated realm. >> >> >> One possibility would be to store it as an internal variable in the >> >> global lexical scope of the respective script. But then we'd need the >> >> preparser to collect respective data about template literals appearing >> >> in lazily parsed functions, so that we can reserve those slots when >> >> compiling a script (or perhaps just one accumulative slot, pointing to >> >> a cache object). >> >> /Andreas >> >> -- >> -- >> v8-users mailing list >> [email protected] >> http://groups.google.com/group/v8-users >> --- >> You received this message because you are subscribed to the Google Groups >> "v8-users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > -- -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
