Bug 194935 - [JSC] putNonEnumerable in JSWrapperMap is too costly
Summary: [JSC] putNonEnumerable in JSWrapperMap is too costly
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Yusuke Suzuki
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2019-02-21 23:06 PST by Yusuke Suzuki
Modified: 2019-02-22 12:21 PST (History)
6 users (show)

See Also:


Attachments
Patch (6.90 KB, patch)
2019-02-21 23:23 PST, Yusuke Suzuki
mark.lam: review+
ews: commit-queue-
Details | Formatted Diff | Diff
Archive of layout-test-results from ews121 for ios-simulator-wk2 (2.47 MB, application/zip)
2019-02-22 07:05 PST, Build Bot
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yusuke Suzuki 2019-02-21 23:06:07 PST
[JSC] putNonEnumerable in JSWrapperMap is too costly
Comment 1 Yusuke Suzuki 2019-02-21 23:23:23 PST
Created attachment 362698 [details]
Patch
Comment 2 Build Bot 2019-02-22 07:05:04 PST
Comment on attachment 362698 [details]
Patch

Attachment 362698 [details] did not pass ios-sim-ews (ios-simulator-wk2):
Output: https://webkit-queues.webkit.org/results/11246612

New failing tests:
fast/viewport/ios/device-width-viewport-after-changing-view-scale.html
Comment 3 Build Bot 2019-02-22 07:05:06 PST
Created attachment 362720 [details]
Archive of layout-test-results from ews121 for ios-simulator-wk2

The attached test failures were seen while running run-webkit-tests on the ios-sim-ews.
Bot: ews121  Port: ios-simulator-wk2  Platform: Mac OS X 10.13.6
Comment 4 Mark Lam 2019-02-22 10:27:55 PST
Comment on attachment 362698 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=362698&action=review

r=me with ChangeLog clarification.

> Source/JavaScriptCore/ChangeLog:8
> +        When we convert Objective-C blocks to JS objects, we need to set up corresponding function object correctly.

set up *a* corresponding ...

> Source/JavaScriptCore/ChangeLog:10
> +        The problem is that this API has particularly costly implementation.

has *a* particularly ...

I also suggest terminating the sentence with a ':' instead of a '.' to indicate that the next line is related to the "costly implementation" that we spoke of here.

> Source/JavaScriptCore/ChangeLog:17
> +        This wraps each JS objects appear in this code with Objective-C wrapper. And we convert a NSDictionary to JSObject, which
> +        has "writable", "enumerable", "configurable", "value" fields, and call the "defineProperty" JS function through Objective-C wrapper.
> +        This allocates many Objective-C wrappers and JS objects for descriptors. Since JSC has a direct C++ API "defineOwnProperty", we should
> +        bypass these Objective-C APIs and call JSC's code directly.

Can you clarify what you meant by "This wraps each JS objects appear in this code with Objective-C wrapper"?

> Source/JavaScriptCore/ChangeLog:22
> +        except for this (converting an Objective-C block to a JS object) one path. And (2) even though [JSValue defineProperty:descriptor] is rewritten,
> +        we still want to call JSC C++ code directly here to avoid NSDictionary allocation for a descriptor.

I suggest rephrasing this as "even if we were to re-write [JSValue defineProperty:descriptor] to be more optimized, we would still want to call the JSC c++ version of defineProperty directly here ..."

> Source/JavaScriptCore/API/JSWrapperMap.mm:187
> +    JSC::JSLockHolder locker(exec);

Let's acquire the locker using the JSLockHolder(VM&) form.  It's more efficient especially since you also need to compute vm here.
Comment 5 Yusuke Suzuki 2019-02-22 12:08:01 PST
Comment on attachment 362698 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=362698&action=review

>> Source/JavaScriptCore/ChangeLog:8
>> +        When we convert Objective-C blocks to JS objects, we need to set up corresponding function object correctly.
> 
> set up *a* corresponding ...

Fixed.

>> Source/JavaScriptCore/ChangeLog:10
>> +        The problem is that this API has particularly costly implementation.
> 
> has *a* particularly ...
> 
> I also suggest terminating the sentence with a ':' instead of a '.' to indicate that the next line is related to the "costly implementation" that we spoke of here.

Nice, fixed.

>> Source/JavaScriptCore/ChangeLog:17
>> +        bypass these Objective-C APIs and call JSC's code directly.
> 
> Can you clarify what you meant by "This wraps each JS objects appear in this code with Objective-C wrapper"?

We have `[@"Object"]` subscript access, then, we get JSObject from GlobalObject["Object"] and wrap it with Objective-C wrapper (JSValue).
Then we invoke a method with objective-C arguments. This converts objective-C arguments into JS values, and then, call the "defineProperty" function, and then get the result, and wrap it with Objective-C wrapper (JSValue) again.

>> Source/JavaScriptCore/ChangeLog:22
>> +        we still want to call JSC C++ code directly here to avoid NSDictionary allocation for a descriptor.
> 
> I suggest rephrasing this as "even if we were to re-write [JSValue defineProperty:descriptor] to be more optimized, we would still want to call the JSC c++ version of defineProperty directly here ..."

Sounds nice! Fixed.

>> Source/JavaScriptCore/API/JSWrapperMap.mm:187
>> +    JSC::JSLockHolder locker(exec);
> 
> Let's acquire the locker using the JSLockHolder(VM&) form.  It's more efficient especially since you also need to compute vm here.

Right, fixed.
Comment 6 Yusuke Suzuki 2019-02-22 12:20:55 PST
Committed r241956: <https://trac.webkit.org/changeset/241956>
Comment 7 Radar WebKit Bug Importer 2019-02-22 12:21:29 PST
<rdar://problem/48320183>