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. > 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.
