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.

Reply via email to