I think that this is great!
I agree with the policy that we should use JSValue everywhere that it would
give us the same codegen/ABI (args in registers, return in registers, etc).
-Filip
> On Jan 3, 2017, at 14:33, Mark Lam <mark....@apple.com> wrote:
>
> Over the holiday period, I looked into the possibility of giving
> EncodedJSValue a default constructor (because I didn’t like having to return
> encodedJSValue() instead of { } in lots of places), and learned why we had
> EncodedJSValue in the first place (i.e. for C linkage). This led me to
> discover (in my reading of the code) that we don’t really need to use
> EncodedJSValue for most of our host functions (those of type NativeFunction,
> GetValueFunc, and PutValueFunc).
>
> I propose that we switch to using JSValue directly where we can. This has
> the benefit of:
> 1. better type safety with the use of JSValue (EncodedJSValue is a int64_t
> typedef).
> 2. more readable code (less marshaling back and forth with
> JSValue::encode()/decode()).
>
> The patch for this change can be found here:
> https://bugs.webkit.org/show_bug.cgi?id=166658
>
> Perf is neutral. Any opinions?
>
> Thanks.
>
> Mark
> _______________________________________________
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
