Bug 195498 - [JSC] Reduce # of structures in JSGlobalObject initialization
Summary: [JSC] Reduce # of structures in JSGlobalObject initialization
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-03-08 17:09 PST by Yusuke Suzuki
Modified: 2019-03-11 14:56 PDT (History)
2 users (show)

See Also:


Attachments
Patch (39.03 KB, patch)
2019-03-08 17:20 PST, Yusuke Suzuki
no flags Details | Formatted Diff | Diff
Patch (39.00 KB, patch)
2019-03-08 17:21 PST, Yusuke Suzuki
no flags Details | Formatted Diff | Diff
Patch (39.01 KB, patch)
2019-03-08 18:34 PST, Yusuke Suzuki
darin: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Yusuke Suzuki 2019-03-08 17:09:51 PST
[JSC] Reduce # of structures in JSGlobalObject initialization
Comment 1 Yusuke Suzuki 2019-03-08 17:20:24 PST
Created attachment 364095 [details]
Patch
Comment 2 Yusuke Suzuki 2019-03-08 17:21:41 PST
Created attachment 364096 [details]
Patch
Comment 3 Yusuke Suzuki 2019-03-08 18:34:51 PST
Created attachment 364106 [details]
Patch
Comment 4 Darin Adler 2019-03-10 13:53:08 PDT
Comment on attachment 364106 [details]
Patch

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

I presume there is enough regression test coverage of these things that we have some good confidence we got them all right.

> Source/JavaScriptCore/runtime/ArrayPrototype.cpp:130
> +    const Identifier unscopableNames[] = {

There is some reference count churn initializing an array of Identifier. Might be nice to look for an idiom with less wasted work. For example, it would be slightly more efficient to make an array of const Identifier* and then dereference all of them to avoid 9 ref/deref pairs.

> Source/JavaScriptCore/runtime/VM.h:572
> +    Structure* setIteratorStructure()
> +    {
> +        if (LIKELY(m_setIteratorStructure))
> +            return m_setIteratorStructure.get();
> +        return setIteratorStructureSlow();
> +    }

I prefer an idiom where we don’t have so many multiline function bodies in a class definition. For me they interfere with my ability to use the class definition to get an overview of what’s in the class. The pattern is also easy to avoid by moving inlines function bodies down in the header, outside the class definition, but with the cost of not being able to see immediately what each function does by seeing its implementation. But it seems that VM already has tons of these. So I don’t think more are going to make things worse.
Comment 5 Yusuke Suzuki 2019-03-11 13:55:18 PDT
Comment on attachment 364106 [details]
Patch

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

>> Source/JavaScriptCore/runtime/ArrayPrototype.cpp:130
>> +    const Identifier unscopableNames[] = {
> 
> There is some reference count churn initializing an array of Identifier. Might be nice to look for an idiom with less wasted work. For example, it would be slightly more efficient to make an array of const Identifier* and then dereference all of them to avoid 9 ref/deref pairs.

`const Identifier*` sounds better. Fixed.

>> Source/JavaScriptCore/runtime/VM.h:572
>> +    }
> 
> I prefer an idiom where we don’t have so many multiline function bodies in a class definition. For me they interfere with my ability to use the class definition to get an overview of what’s in the class. The pattern is also easy to avoid by moving inlines function bodies down in the header, outside the class definition, but with the cost of not being able to see immediately what each function does by seeing its implementation. But it seems that VM already has tons of these. So I don’t think more are going to make things worse.

I leave it as is since (1) as you said, VM already has bunch of inlined functions in class declaration, and (2) it is aligned to the existing lazy allocation methods in VM.
I think we can clean up VM at some point.
Comment 6 Yusuke Suzuki 2019-03-11 14:55:05 PDT
Committed r242742: <https://trac.webkit.org/changeset/242742>
Comment 7 Radar WebKit Bug Importer 2019-03-11 14:56:29 PDT
<rdar://problem/48784197>