[resending because v8-users rejects email from non-subscribers] Right, you cannot tell in general whether something can be serialized without side effects (though you can tell that certain things definitely won't have side effects). And if the spec says the value should be serialized (or content expects it), not doing so is a web-visible behavior change at present (albeit reasonably likely to be web-compatible).
I would worry about the performance of such an observer, and it seems like the observer would also need to be fairly complicated anyway in general. For example, you might want key path "b.c.d", but b.c turns out to just be a back-reference to a.x earlier (which the serializer basically knows as an object index at that point), so you might need to reconstruct a substantial part of the object graph anyway. I don't think it's off the table, but it seems quite non-trivial if you want this to be a general solution. If the typical cases are fairly simple, then it seems like we just be pretty naive and only proceed if all we see are simple objects with no accessors properties/interceptors/etc and fall back to whatever we currently do if that isn't the case. That seems somewhat duplicative, sure, but seems like it would give you 90%+ coverage with much less complexity. On Wed, Aug 5, 2020 at 8:20 PM Adam Klein <ad...@chromium.org> wrote: > On Tue, Aug 4, 2020 at 1:32 PM Adrienne Walker <e...@chromium.org> wrote: > >> On Thu, Jul 30, 2020 at 9:57 PM Ben Noordhuis <i...@bnoordhuis.nl> wrote: >> >>> On Thu, Jul 30, 2020 at 8:21 PM Adrienne Walker <e...@chromium.org> >>> wrote: >>> > Is there any way to know from a v8::Value whether serializing it will >>> have side effects (at all or on particular properties)? >>> >>> Apart from checking whether it's primitive (v->IsNullOrUndefined() || >>> v->IsBoolean() || ...), I believe the answer is 'no' . Non-primitive >>> values can have getters and getters execute arbitrary code. >>> >>> Checking for only simple properties recursively is an option but >>> probably not faster and you'll need to handle cycles and a ton of edge >>> cases (what if the property is a pending promise? what if it's a >>> WeakMap? etc.) >>> >> >> Can I use HasRealNamedProperty/GetRealNamedProperty to see if I can >> access those properties without side effects and then check if those values >> are primitive from there? I suspect that most indexeddb keys being provided >> here are primitive string values inside a single simple object, and so am I >> trying to figure out how to fast path this case. Is there a way to tell if >> a property is one of these complicated edge cases that you mention? >> >> >>> The debugger has a "side-effect-free evaluate" mode but that operates >>> on functions, not values. You could use it to check getters for side >>> effects (and promises, and...) but the algorithm is conservative (can >>> report side effects when there are none) and runs in O(n) time >>> relative to the function's bytecode size. >> >> >> Given the potential performance issues there, this doesn't sound like a >> plausible approach. >> >> The only other thing we thought of was if there was some way to have some >> sort of observer as a part of serialization that could record the values >> without having to deserialize again to access. I worry that this might be >> too invasive to v8's serialization though. >> > > To the question of whether something might be "invasive to v8's > serialization", I think the history here is important: serialization used > to live in Blink, but was moved into V8 (by jbroman@, CCed) for > performance reasons. Given that the problem you're investigating is another > performance issue in serialization, making such an invasive change should > at least be on the table, I'd argue. > > - Adam > > >> -- >> -- >> v8-users mailing list >> v8-users@googlegroups.com >> 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 v8-users+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/v8-users/CA%2B1_fV8rAhA8arck6C%2BXoQC%3DaMx1S_cARXGbymiG-%3DCHko3_5Q%40mail.gmail.com >> <https://groups.google.com/d/msgid/v8-users/CA%2B1_fV8rAhA8arck6C%2BXoQC%3DaMx1S_cARXGbymiG-%3DCHko3_5Q%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- -- v8-users mailing list v8-users@googlegroups.com 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 v8-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/CACuR13dUi4osh7xWEFvjdp3etUACcATa_VqV3xWM%3Da8n3Ku07A%40mail.gmail.com.
