It is true that Scripts are already listed in the weak array list. However, that's hidden in V8. So if we were to keep a weak list of scripts to metadata mapping, that would work fine. If we did this on the embedder side, then we'd need something else than script IDs as keys.
Looking forward to your patch :) Yang On Mon, Feb 22, 2021 at 1:55 PM Alex Kodat <ako...@rocketsoftware.com> wrote: > Yang, > > Thanks for your response. I've decided to bail out on the metadata part of > my proposal for the very reason you indicated -- it's kind of a niche > application and, in many ways, a time-based cache makes more sense for my > application. I'll submit a CL soon to add GitScriptSource > and GetScriptSourceMappingURL methods to StackFrame. These are very > straightforward, require no data structure changes and expose nothing > unless an embedder choses to do so. Hopefully this is OK. > > Not that its important but I'm a little puzzled by your comment about the > weak map. Scripts are already managed via a WeakArrayList -- functionality > that would be nice in JS but, of course, only usable because the iterator > is able to block GC while it's alive and, of course, exposing something > like that in JS would be a bad idea. > > Cheers, > Alex > > On Monday, February 22, 2021 at 3:40:07 AM UTC-6 Yang Guo wrote: > >> To understand this a bit better, the reason a map from script to metadata >> doesn't work for you, when implemented on the embedder side, is that you >> can't have a weak map with script IDs as keys? >> >> I'm concerned that since this seems like a niche use case, adding >> another field to Script objects is not a good idea. So we'd have to >> implement that as a weak map inside of V8 either way. >> >> Cheers, >> >> Yang >> >> >> >> On Wed, Feb 17, 2021 at 5:52 PM Alex Kodat <ako...@rocketsoftware.com> >> wrote: >> >>> Thanks Yang, >>> >>> FWIW, it appears that one can effectively disable the prepareStackTrace >>> API by setting Error.stackTraceLimit to 0. Fortunately, this does not >>> affect Exception::StackTrace. But you knew that. >>> >>> My impression of import.meta is that it's a way of the environment >>> passing information into a module, presumably information about the module >>> itself. >>> >>> My ScriptMetadata proposal is more about maintaining information about >>> the script for use outside of the script though it could, in theory, be >>> exposed inside a script if an embedder chooses to do so (doubt if we >>> would). >>> >>> I guess one similarity to import.meta is the >>> read-only/lazy-instantiation of ScriptMetadata so, like import.meta, if >>> it's not used, there's no cost but once it's set, it can't be changed. Also >>> ScriptMetadata and import.meta would have lifetimes that would tend to >>> follow the lifetimes of the corresponding script or module which is why >>> ScriptMetadata would be useful. >>> >>> On Wednesday, February 17, 2021 at 8:37:50 AM UTC-6 Yang Guo wrote: >>> >>>> Hi, >>>> >>>> I think the hurdle for a C++ API is a lot lower, and I can see the >>>> usefulness of GetScriptSource as you suggest. >>>> >>>> I'm somewhat indifferent about a metadata object. Isn't that a bit like >>>> import.meta for modules? >>>> >>>> Cheers, >>>> >>>> Yang >>>> >>>> >>>> >>>> On Wed, Feb 17, 2021 at 2:43 PM Alex Kodat <ako...@rocketsoftware.com> >>>> wrote: >>>> >>>>> Thanks Yang, >>>>> >>>>> Got it on prepareStackTrace -- it's a funny and sketchy beast. getThis >>>>> and getFunction are particularly beyond the pale in terms of >>>>> encapsulation. >>>>> In fact, it wouldn't hurt to have a flag to disable the API. >>>>> >>>>> In hindsight, the right solution is for me to use >>>>> Exception::GetStackTrace and the StackFrame class. This does have the >>>>> ScriptId. I guess I had it in my head that prepareStackTrace was the >>>>> preferred API. Clearly not. ;-) >>>>> >>>>> So changing my proposal to adding a Local<Value> GetScriptSource to >>>>> StackFrame. The idea is to prevent storage leaks by eliminating the need >>>>> to >>>>> manage script source external to the internal Script as it's very >>>>> difficult >>>>> to manage the lifetime of the source that way. By providing access to the >>>>> source via the internal Script, the lifetime is nicely managed for us. >>>>> This >>>>> seems pretty safe from a security/encapsulation perspective as embedders >>>>> can limit access to this information as they see fit. >>>>> >>>>> It would also be useful to have a Local<Object> GetScriptMetadata (or >>>>> GetScriptMemo?) in StackFrame to allow memoization of the script data. The >>>>> metadata object could be lazily instantiated and again, would reduce the >>>>> risk of storage leaks as the lifetime of the ScriptMetadata would >>>>> generally >>>>> match the lifetime of the internal Script object. UnboundScript and maybe >>>>> Module could also have a GetScriptMetadata to provide access to the same >>>>> object. >>>>> >>>>> Might either of these be more palatable? >>>>> >>>>> On Wednesday, February 17, 2021 at 4:07:31 AM UTC-6 Yang Guo wrote: >>>>> >>>>>> Generally I would discourage adding more non-spec features to the >>>>>> V8's JS implementation. In the long run, these non-spec features cause >>>>>> compatibility problems, and often are a security nightmare. They also add >>>>>> unnecessary complexity to maintain. The reason we have not removed the >>>>>> prepareStackTrace API is because it was introduced more than 10 years >>>>>> ago, >>>>>> and so much existing code already relies on it. We would not have >>>>>> introduced it today. Providing this non-spec feature is already causing >>>>>> unnecessary memory leaks in some cases, and exposing script source as you >>>>>> suggest is not going to improve that. >>>>>> >>>>>> I'm also skeptical about exposing the script ID. We only expose it >>>>>> via Chrome DevTools protocol, which is orthogonal to the JS-accessible >>>>>> stack trace API. >>>>>> >>>>>> +Shu-yu Guo to maybe provide another perspective. >>>>>> >>>>>> I'd encourage you to use the Chrome DevTools protocol to achieve what >>>>>> you are trying to do. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Yang >>>>>> >>>>>> On Wed, Feb 17, 2021 at 5:42 AM Alex Kodat <ako...@rocketsoftware.com> >>>>>> wrote: >>>>>> >>>>>>> In managing a menagerie of scripts from various sources, I've found >>>>>>> it useful to enhance CallSite locally to have two additional functions >>>>>>> getScriptId and getScriptSource. The former provides a unique identifier >>>>>>> for the script that contains the code in the stack frame and the latter >>>>>>> access to the script source so one can say extract a sourceMappingUrl or >>>>>>> display more than one line around the point of error or show source >>>>>>> lines >>>>>>> in a stack trace or whatever. While it's possible to maintain a table of >>>>>>> source ourselves (the scriptId would be helpful in managing such a >>>>>>> table) >>>>>>> there's no great way of managing the lifespan of entries in the table >>>>>>> so it >>>>>>> seems useful to be able to get access to the source via the Script >>>>>>> object >>>>>>> which manages the lifespan of the source nicely. >>>>>>> >>>>>>> It was pretty trivial to add these so it doesn't seem like there's a >>>>>>> major downside, so does it seem reasonable to submit a CL for this? I'd >>>>>>> offer to fix up the doc at https://v8.dev/docs/stack-trace-api if >>>>>>> it does, but, of course, I don't have access. >>>>>>> >>>>>>> A bit more controversial, perhaps, would be that it seems it would >>>>>>> be useful to add a lazily instantiated metadata object on (internal) >>>>>>> Script >>>>>>> objects. A CallSite could have a getScriptMetadata function to provide >>>>>>> access to this object. Similarly, maybe a GetScriptMetadata method for >>>>>>> the >>>>>>> UnboundScript and maybe Module and Function classes would also provide >>>>>>> access to the object. The first request for the ScriptMetadata could >>>>>>> create >>>>>>> an empty JS Object which could then be used by apps to store script >>>>>>> metadata such as, for example, a dereferenced sourceMappingURL. Again, >>>>>>> we >>>>>>> could manage such metadata externally ourselves but it's a major pain >>>>>>> managing the lifespan of such metadata, especially as there's no way of >>>>>>> having a direct weak reference to the internal Script object -- the >>>>>>> closest >>>>>>> we can get is a weak reference to the UnboundScript which is a proxy for >>>>>>> the SharedFunctionInfo which isn't quite right but might be workable. >>>>>>> >>>>>>> Does ScriptMetadata sound too crazy/special-purpose or should I try >>>>>>> coding it up and submitting a CL and let the reviewers judge if the pain >>>>>>> justifies the gain? >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> -- >>>>>>> -- >>>>>>> v8-dev mailing list >>>>>>> v8-...@googlegroups.com >>>>>>> http://groups.google.com/group/v8-dev >>>>>>> --- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "v8-dev" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to v8-dev+un...@googlegroups.com. >>>>>>> To view this discussion on the web visit >>>>>>> https://groups.google.com/d/msgid/v8-dev/46c81d5a-e18e-43fe-b1ae-80002cbd56d8n%40googlegroups.com >>>>>>> <https://groups.google.com/d/msgid/v8-dev/46c81d5a-e18e-43fe-b1ae-80002cbd56d8n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>> . >>>>>>> >>>>>> -- >>>>> -- >>>>> v8-dev mailing list >>>>> v8-...@googlegroups.com >>>>> http://groups.google.com/group/v8-dev >>>>> --- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "v8-dev" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to v8-dev+un...@googlegroups.com. >>>>> >>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/v8-dev/2f6aaef5-4d2f-4c29-9df6-0ed133e0143fn%40googlegroups.com >>>>> <https://groups.google.com/d/msgid/v8-dev/2f6aaef5-4d2f-4c29-9df6-0ed133e0143fn%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >>> -- >>> v8-dev mailing list >>> v8-...@googlegroups.com >>> http://groups.google.com/group/v8-dev >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "v8-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to v8-dev+un...@googlegroups.com. >>> >> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/v8-dev/37509e39-de36-445a-8990-0eec38a9363cn%40googlegroups.com >>> <https://groups.google.com/d/msgid/v8-dev/37509e39-de36-445a-8990-0eec38a9363cn%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- > -- > v8-dev mailing list > v8-dev@googlegroups.com > http://groups.google.com/group/v8-dev > --- > You received this message because you are subscribed to the Google Groups > "v8-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to v8-dev+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/v8-dev/8efe618c-26c0-4b08-ab3f-27dac6765209n%40googlegroups.com > <https://groups.google.com/d/msgid/v8-dev/8efe618c-26c0-4b08-ab3f-27dac6765209n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- -- v8-dev mailing list v8-dev@googlegroups.com http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/CAFSTc_g1PRVKsAv_5U_MTcuQbrVGtuzoGtMz1zEq-q4KwdSStg%40mail.gmail.com.
