Bug 205769 - JSON.parse should lookup prototype chains during revival
Summary: JSON.parse should lookup prototype chains during revival
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: WebKit Nightly Build
Hardware: All All
: P2 Trivial
Assignee: Alexey Shvayka
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2020-01-04 14:54 PST by Alexey Shvayka
Modified: 2020-03-06 13:59 PST (History)
9 users (show)

See Also:


Attachments
Patch (4.76 KB, patch)
2020-01-04 15:23 PST, Alexey Shvayka
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alexey Shvayka 2020-01-04 14:54:06 PST
ECMA262: https://tc39.es/ecma262/#sec-internalizejsonproperty (step 1)
Test262:
  https://test262.report/browse/built-ins/JSON/parse/reviver-array-get-prop-from-prototype.js
  https://test262.report/browse/built-ins/JSON/parse/reviver-object-get-prop-from-prototype.js

Currently, JSC gets only own properties. ChakraCore fails array test, yet passes the object test.
Related steps of InternalizeJSONProperty were not normatively changed since ES5.
Comment 1 Alexey Shvayka 2020-01-04 15:23:04 PST
Created attachment 386770 [details]
Patch
Comment 2 Darin Adler 2020-01-06 13:28:51 PST
Comment on attachment 386770 [details]
Patch

I wanted to review this, and the change seems clean and straightforward, but I’m not enough expert on what optimization might be lost by using the get functions in the most ordinary way. My guess is that there’s no downside to this change, but I don’t feel that I am completely qualified.

Someone with more recent understanding of the runtime could weigh in on that point.
Comment 3 Saam Barati 2020-01-17 00:06:25 PST
Comment on attachment 386770 [details]
Patch

r=me
Comment 4 Saam Barati 2020-01-17 00:07:57 PST
(In reply to Darin Adler from comment #2)
> Comment on attachment 386770 [details]
> Patch
> 
> I wanted to review this, and the change seems clean and straightforward, but
> I’m not enough expert on what optimization might be lost by using the get
> functions in the most ordinary way. My guess is that there’s no downside to
> this change, but I don’t feel that I am completely qualified.
> 
> Someone with more recent understanding of the runtime could weigh in on that
> point.

It should be the essentially the same speed based on my reading of the code. Where it’s not is where we’re actually doing more work in order to follow the spec, when we traverse up the prototype chain searching for the property.
Comment 5 Alexey Shvayka 2020-01-17 11:47:20 PST
Comment on attachment 386770 [details]
Patch

Thank you for reviews, folks. I've paused the commit queue to run some microbenchmarks: no measurable regression.

Cold runs, --outer 8:

                                   TipOfTree              patch

json-parse-array-reviver       193.4741+-1.9814      196.1498+-1.9866
json-parse-object-reviver      218.0244+-1.2942      217.8842+-1.4113

<geometric>                    205.3828+-1.6014      206.7316+-1.6745
Comment 6 WebKit Commit Bot 2020-01-17 12:22:03 PST
Comment on attachment 386770 [details]
Patch

Clearing flags on attachment: 386770

Committed r254757: <https://trac.webkit.org/changeset/254757>
Comment 7 WebKit Commit Bot 2020-01-17 12:22:04 PST
All reviewed patches have been landed.  Closing bug.
Comment 8 Radar WebKit Bug Importer 2020-01-17 12:23:14 PST
<rdar://problem/58691323>