Bug 212248 - hasOwnProperty inside structure property for-in loop should use an opcode like has_structure_property but for hasOwnProperty
Summary: hasOwnProperty inside structure property for-in loop should use an opcode lik...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Saam Barati
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2020-05-21 19:31 PDT by Saam Barati
Modified: 2020-07-15 00:36 PDT (History)
14 users (show)

See Also:


Attachments
patch (60.68 KB, patch)
2020-05-26 21:56 PDT, Saam Barati
no flags Details | Formatted Diff | Diff
patch (63.04 KB, patch)
2020-05-27 10:31 PDT, Saam Barati
no flags Details | Formatted Diff | Diff
patch (62.68 KB, patch)
2020-05-27 12:03 PDT, Saam Barati
keith_miller: review+
Details | Formatted Diff | Diff
patch for landing (63.68 KB, patch)
2020-05-27 17:50 PDT, Saam Barati
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Saam Barati 2020-05-21 19:31:09 PDT
...
Comment 1 Saam Barati 2020-05-26 13:31:39 PDT
patch forthcoming

Appears to speedup React in Speedo2 by ~5%
Comment 2 Saam Barati 2020-05-26 21:56:09 PDT
Created attachment 400310 [details]
patch
Comment 3 Saam Barati 2020-05-27 10:31:46 PDT
Created attachment 400349 [details]
patch
Comment 4 Saam Barati 2020-05-27 12:03:03 PDT
Created attachment 400364 [details]
patch

rebased
Comment 5 Keith Miller 2020-05-27 16:04:04 PDT
Comment on attachment 400364 [details]
patch

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

r=me with comments.

> Source/JavaScriptCore/bytecode/BytecodeList.rb:1108
> +op :has_self_structure_property,

Wouldn't this normally be own? I guess we use the terms interchangeably though.

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:5247
> +        unsigned newTarget = std::get<1>(hasOwnPropertyTuple);

Like new.target? :P

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:5257
> +        // disable peephole optimizations
> +        generator.m_lastOpcodeID = op_end;

Nit: Can we make this a function on BytecodeGenerator?

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:5259
> +        OpJmp::emit<OpcodeSize::Wide32>(&generator, BoundLabel(static_cast<int>(newTarget) - static_cast<int>(branchInstIndex)));

Why does this have to be Wide32 if we are gonna Nop fill anyway?
Comment 6 Saam Barati 2020-05-27 17:23:32 PDT
Comment on attachment 400364 [details]
patch

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

>> Source/JavaScriptCore/bytecode/BytecodeList.rb:1108
>> +op :has_self_structure_property,
> 
> Wouldn't this normally be own? I guess we use the terms interchangeably though.

I can switch to own, it's probably more consistent

>> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:5247
>> +        unsigned newTarget = std::get<1>(hasOwnPropertyTuple);
> 
> Like new.target? :P

haha I thought this too when writing it, but kept it given context
I can switch to newBranchTarget

>> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:5257
>> +        generator.m_lastOpcodeID = op_end;
> 
> Nit: Can we make this a function on BytecodeGenerator?

sure

>> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:5259
>> +        OpJmp::emit<OpcodeSize::Wide32>(&generator, BoundLabel(static_cast<int>(newTarget) - static_cast<int>(branchInstIndex)));
> 
> Why does this have to be Wide32 if we are gonna Nop fill anyway?

Good point, I don't think it does.
Comment 7 Saam Barati 2020-05-27 17:50:37 PDT
Created attachment 400411 [details]
patch for landing
Comment 8 EWS 2020-05-27 19:43:30 PDT
Committed r262233: <https://trac.webkit.org/changeset/262233>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 400411 [details].
Comment 9 Radar WebKit Bug Importer 2020-05-27 19:44:20 PDT
<rdar://problem/63701395>
Comment 10 Caio Lima 2020-05-28 06:47:17 PDT
Comment on attachment 400411 [details]
patch for landing

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

> Source/JavaScriptCore/runtime/JSGlobalObject.cpp:1053
> +        JSValue hasOwnPropertyFunction = jsCast<JSFunction*>(objectPrototype()->get(this, vm.propertyNames->hasOwnProperty));

Is there a reason to not use `getDirect()` here? Anyway, if we want to keep using `get`, we need to add a `catchScope.assertNoException()` after this call. Right now this is breaking almost all tests on Debug builds https://build.webkit.org/builders/Apple-Catalina-Debug-JSC-Tests
Comment 11 Mark Lam 2020-05-28 07:30:08 PDT
(In reply to Caio Lima from comment #10)
> we need to add a `catchScope.assertNoException()` after this

Landed r262239: <http://trac.webkit.org/r262239> to placate the exception checker and green the bots.
Comment 12 Saam Barati 2020-05-28 09:20:06 PDT
(In reply to Caio Lima from comment #10)
> Comment on attachment 400411 [details]
> patch for landing
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=400411&action=review
> 
> > Source/JavaScriptCore/runtime/JSGlobalObject.cpp:1053
> > +        JSValue hasOwnPropertyFunction = jsCast<JSFunction*>(objectPrototype()->get(this, vm.propertyNames->hasOwnProperty));
> 
> Is there a reason to not use `getDirect()` here? Anyway, if we want to keep
> using `get`, we need to add a `catchScope.assertNoException()` after this
> call. Right now this is breaking almost all tests on Debug builds
> https://build.webkit.org/builders/Apple-Catalina-Debug-JSC-Tests

The reason was just not relying on it being in Structure property storage.

But we could also just use getDirect, since this will likely lead to failures in testing if ObjectPrototype ever puts hasOwnProperty elsewhere that isn't in property storage