[webkit-dev] Reducing the use of EncodedJSValue and use JSValue directly instead.

[JF Bastien]

On Tue, Jan 3, 2017 at 2:54 PM, Geoffrey Garen <ggaren at apple.com> wrote:

> EncodedJSValue was always just a work-around to convince the compiler to
> put a JSValue in registers (instead of on the stack, with different
> compilers disagreeing about where on the stack).
>
> I agree with removing EncodedJSValue if possible.
>
> Did something change to make this possible? For example, are you sure that
> Windows and 32bit are OK with this change?
>

Recent MSVC seems happy, 32- and 64-bit: https://godbolt.org/g/XVaDyz
Unless you had another example in mind?


I don’t understand why C linkage would affect things: Either the compiler
> puts structs in registers or it doesn’t.
>
> Geoff
>
> On Jan 3, 2017, at 2:44 PM, Filip Pizlo <fpizlo at apple.com> wrote:
>
> 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.lam at 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 at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20170103/1485939d/attachment.html>