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-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/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-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_hQr8ZYT%2Bsxuc%2BMdQag%3DLFSFLY9FANJ5VUtQe8PiL9uPw%40mail.gmail.com.
