On Tue, Aug 4, 2020 at 10: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.
Yes, that could work, but you'll have to recurse into non-primitive property values. GetRealNamedProperty() and co are fairly slow (although probably not much slower than Get() - the whole C++ API is fairly slow compared to native JS property access) so you'll probably have to benchmark whether it's an improvement over the naive approach. > Is there a way to tell if a property is one of these complicated edge cases > that you mention? Exhaustive v->IsPromise() || v->IsWeakMap() || ... checks. :-) >> 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. -- -- 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/CAHQurc8t2V3UykM5EBNrmZHApEYoDmzdiLKcdz-gbvoLuya1tQ%40mail.gmail.com.