1787350 - Spec compliance and implementation simplifications for Record and Tuple properties and prototypes

Status: NEW

(Core :: JavaScript Engine, task, P2)

Description

[Tim Chevalier]

A change introduced in https://phabricator.services.mozilla.com/D131124 added special handling for record and tuple wrappers to allow them to be both non-extensible and lazily resolved. (That is, properties were copied from the underlying primitive record or tuple into the wrapper only when accessed.) This follows the treatment of string wrappers, but string wrappers are extensible.

I discussed this with Nicolò and we agreed that we don't think this is necessary. Record and tuple wrappers are usually optimized away. The potential performance cost of copying all properties eagerly on wrapper creation has to be weighed with the benefits of eliminating record-and-tuple-specific changes from the code paths for Objects.

I'm about to submit a patch for this.

Comment 1

[Tim Chevalier]

Attachment: Bug 1787350: Eagerly resolve properties for record and tuple wrappers r?jandem

Previously, Object wrappers for records and tuples had lazily resolved
properties, similarly to string properties. This is an optimization that saves
time and space by only copying properties from the primitive into the wrapper
as needed.

However, this creates complications for records and tuples, since unlike
strings, their wrappers are frozen. This commit eliminates several special
cases from object operations by eliminating lazy resolution for record and
tuple wrapper objects. Instead, constructing a RecordObject or
TupleObject eagerly copies the properties. We don't expect this to cause
a performance issue since record and tuple wrappers can usually be optimized
away, but time will tell.

Comment 2

[Tim Chevalier]

I renamed the bug so that a few other fixes can be included in the same patch stack:

• Add length as an own property (formerly bug 1777761)
• Tuple.prototype should have a null prototype (proposal section 14.2.3: https://tc39.es/proposal-record-tuple/#sec-properties-of-the-tuple-prototype-object )
• Tuple wrappers should not inherit indexed properties from the prototype (proposal section 10.4.9.5: https://tc39.es/proposal-record-tuple/#sec-tuple-exotic-objects-get-p-receiver )

Comment 4

[Tim Chevalier]

Attachment: Bug 1787350: Tuple.prototype should have a null prototype r?jandem

As per section 14.2.3 of the Record and Tuple proposal -
https://tc39.es/proposal-record-tuple/#sec-properties-of-the-tuple-prototype-object

• the Tuple prototype object has its prototype set to null. Previously,
  it inherited from Object.prototype.

Depends on D155642

Comment 5

[Tim Chevalier]

Attachment: Bug 1787350: Skip proto chain lookups for out-of-range tuple elements r?anba

As per step 3.b.ii of [[Get]] for tuple wrappers given in section
10.4.9.5 of the Record and Tuple proposal:
https://tc39.es/proposal-record-tuple/#sec-tuple-exotic-objects-get-p-receiver

when a numeric property key P is outside the valid range of indices for a
given tuple wrapper, Get(P) should immediately return undefined rather
than searching the prototype change.

This patch extends the existing special case for TypedArray to
partially apply to TupleObject as well.

Depends on D156135

Comment 6

[Tim Chevalier]

Attachment: Bug 1787350: Record and Tuple conformance tests r?jandem

Adds conformance tests for section 10.4.9 of the Record and Tuple proposal -
https://tc39.es/proposal-record-tuple/#sec-tuple-exotic-objects

as well as tests reflecting that length is an own property as per
section 10.4.9.2,
https://tc39.es/proposal-record-tuple/#sec-tuple-exotic-objects-getownproperty-p

Depends on D156136

Comment 7

[Tim Chevalier]

Adding one more spec compliance bug: Record.prototype should be null (proposal section 14.1.2.3: https://tc39.es/proposal-record-tuple/#sec-record.prototype ).

Comment 8

[Tim Chevalier]

Attachment: Bug 1787350: Set `Record.prototype` to null r?jandem

As per section 14.1.2.3 of the Record and Tuple proposal -
https://tc39.es/proposal-record-tuple/#sec-record.prototype - set
Record.prototype to null and initialize RecordObjects with a null
prototype

Comment 9

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.