[builtins] DeleteProperty: Handle last-added fast properties

[builtins] DeleteProperty: Handle last-added fast properties

In general, deleting a property from a fast-properties object
requires transitioning the object to dictionary mode. However,
when the most-recently-added property is deleted, we can simply
roll back the last map transition that the object went through.

This is a performance experiment: it should make things faster,
but if it turns out to have more negative than positive impact,
we will have to revert it.

TBR=bmeurer@chromium.org (just adding a comment)

Review-Url: https://codereview.chromium.org/2830093002
Cr-Commit-Position: refs/heads/master@{#44799}
Committed: https://chromium.googlesource.com/v8/v8/+/98acfb36e1acf2ab52ab6b6439eb6356c83dcda6

[Jakob Kummerow, 2017-04-20 18:21:25]

jkummerow@chromium.org changed reviewers:
+ ishell@chromium.org

[Jakob Kummerow, 2017-04-20 18:21:25]

PTAL.

[Igor Sheludko, 2017-04-21 14:17:50]

lgtm with nits:

https://codereview.chromium.org/2830093002/diff/1/src/builtins/builtins-inter...
File src/builtins/builtins-internal-gen.cc (right):

https://codereview.chromium.org/2830093002/diff/1/src/builtins/builtins-inter...
src/builtins/builtins-internal-gen.cc:206: // (and not e.g. an elements kind
change).
(and not any kind of special transition).

https://codereview.chromium.org/2830093002/diff/1/src/builtins/builtins-inter...
src/builtins/builtins-internal-gen.cc:241: StoreFixedArrayElement(properties,
backing_store_index, filler);
We can skip write barrier here because UndefinedValue is immortal immovable.
Maybe also add a DCHECK(Heap::RootIsImmortalImmovable(...)).

https://codereview.chromium.org/2830093002/diff/1/src/ic/accessor-assembler.cc
File src/ic/accessor-assembler.cc (right):

https://codereview.chromium.org/2830093002/diff/1/src/ic/accessor-assembler.c...
src/ic/accessor-assembler.cc:1070: GotoIf(IntPtrOrSmiLessThan(new_index, length,
mode), &done);
Probably the following code would be a bit more readable:

Node* offset = DecodeWord<StoreHandler::FieldOffsetBits>(handler_word);
Node* size = ElementOffsetFromIndex(length, FAST_ELEMENTS, mode,
FixedArray::kHeaderSize);
GotoIf(UintPtrLessThan(offset, size, mode), &done);

[Igor Sheludko, 2017-04-21 14:20:49]

https://codereview.chromium.org/2830093002/diff/1/src/builtins/builtins-inter...
File src/builtins/builtins-internal-gen.cc (right):

https://codereview.chromium.org/2830093002/diff/1/src/builtins/builtins-inter...
src/builtins/builtins-internal-gen.cc:235: StoreObjectField(receiver,
field_offset, filler);
... and here.

[Jakob Kummerow, 2017-04-21 17:49:31]

Thanks for the review! All comments addressed.

https://codereview.chromium.org/2830093002/diff/1/src/builtins/builtins-inter...
File src/builtins/builtins-internal-gen.cc (right):

https://codereview.chromium.org/2830093002/diff/1/src/builtins/builtins-inter...
src/builtins/builtins-internal-gen.cc:206: // (and not e.g. an elements kind
change).
On 2017/04/21 14:17:50, Igor Sheludko wrote:
> (and not any kind of special transition).

Done.

https://codereview.chromium.org/2830093002/diff/1/src/builtins/builtins-inter...
src/builtins/builtins-internal-gen.cc:235: StoreObjectField(receiver,
field_offset, filler);
On 2017/04/21 14:20:49, Igor Sheludko wrote:
> ... and here.

Done.

https://codereview.chromium.org/2830093002/diff/1/src/builtins/builtins-inter...
src/builtins/builtins-internal-gen.cc:241: StoreFixedArrayElement(properties,
backing_store_index, filler);
On 2017/04/21 14:17:50, Igor Sheludko wrote:
> We can skip write barrier here because UndefinedValue is immortal immovable.
> Maybe also add a DCHECK(Heap::RootIsImmortalImmovable(...)).

Done.

https://codereview.chromium.org/2830093002/diff/1/src/ic/accessor-assembler.cc
File src/ic/accessor-assembler.cc (right):

https://codereview.chromium.org/2830093002/diff/1/src/ic/accessor-assembler.c...
src/ic/accessor-assembler.cc:1070: GotoIf(IntPtrOrSmiLessThan(new_index, length,
mode), &done);
On 2017/04/21 14:17:50, Igor Sheludko wrote:
> Probably the following code would be a bit more readable:
> 
> Node* offset = DecodeWord<StoreHandler::FieldOffsetBits>(handler_word);
> Node* size = ElementOffsetFromIndex(length, FAST_ELEMENTS, mode,
> FixedArray::kHeaderSize);
> GotoIf(UintPtrLessThan(offset, size, mode), &done);

Thanks, that's much better. Done.

[Jakob Kummerow, 2017-04-21 17:49:38]

The CQ bit was checked by jkummerow@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-04-21 17:49:51]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-04-21 18:17:04]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-04-21 18:17:05]

Dry run: This issue passed the CQ dry run.

[Jakob Kummerow, 2017-04-24 12:44:46]

The CQ bit was checked by jkummerow@chromium.org

[Jakob Kummerow, 2017-04-24 12:44:46]

The patchset sent to the CQ was uploaded after l-g-t-m from ishell@chromium.org
Link to the patchset: https://codereview.chromium.org/2830093002/#ps20001
(title: "addressed comments")

[commit-bot: I haz the power, 2017-04-24 12:44:54]

CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-04-24 12:47:39]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-04-24 12:47:40]

Try jobs failed on following builders:
  v8_presubmit on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_presubmit/builds/39626)

[Jakob Kummerow, 2017-04-24 13:22:26]

Description was changed from

==========
[builtins] DeleteProperty: Handle last-added fast properties

In general, deleting a property from a fast-properties object
requires transitioning the object to dictionary mode. However,
when the most-recently-added property is deleted, we can simply
roll back the last map transition that the object went through.

This is a performance experiment: it should make things faster,
but if it turns out to have more negative than positive impact,
we will have to revert it.
==========

to

==========
[builtins] DeleteProperty: Handle last-added fast properties

In general, deleting a property from a fast-properties object
requires transitioning the object to dictionary mode. However,
when the most-recently-added property is deleted, we can simply
roll back the last map transition that the object went through.

This is a performance experiment: it should make things faster,
but if it turns out to have more negative than positive impact,
we will have to revert it.

TBR=bmeurer@chromium.org (just adding a comment)
==========

[Jakob Kummerow, 2017-04-24 13:22:36]

The CQ bit was checked by jkummerow@chromium.org

[commit-bot: I haz the power, 2017-04-24 13:22:46]

CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-04-24 13:27:42]

CQ is committing da patch.

Bot data: {"patchset_id": 20001, "attempt_start_ts": 1493040156215820,
"parent_rev": "7079d41a8172fbb3504945ec9cd634eb095f7b2b", "commit_rev":
"98acfb36e1acf2ab52ab6b6439eb6356c83dcda6"}

[commit-bot: I haz the power, 2017-04-24 13:27:48]

Description was changed from

==========
[builtins] DeleteProperty: Handle last-added fast properties

In general, deleting a property from a fast-properties object
requires transitioning the object to dictionary mode. However,
when the most-recently-added property is deleted, we can simply
roll back the last map transition that the object went through.

This is a performance experiment: it should make things faster,
but if it turns out to have more negative than positive impact,
we will have to revert it.

TBR=bmeurer@chromium.org (just adding a comment)
==========

to

==========
[builtins] DeleteProperty: Handle last-added fast properties

In general, deleting a property from a fast-properties object
requires transitioning the object to dictionary mode. However,
when the most-recently-added property is deleted, we can simply
roll back the last map transition that the object went through.

This is a performance experiment: it should make things faster,
but if it turns out to have more negative than positive impact,
we will have to revert it.

TBR=bmeurer@chromium.org (just adding a comment)

Review-Url: https://codereview.chromium.org/2830093002
Cr-Commit-Position: refs/heads/master@{#44799}
Committed:
https://chromium.googlesource.com/v8/v8/+/98acfb36e1acf2ab52ab6b6439eb6356c83...
==========

[commit-bot: I haz the power, 2017-04-24 13:27:49]

Committed patchset #2 (id:20001) as
https://chromium.googlesource.com/v8/v8/+/98acfb36e1acf2ab52ab6b6439eb6356c83...

[Michael Achenbach, 2017-04-24 14:52:38]

A revert of this CL (patchset #2 id:20001) has been created in
https://codereview.chromium.org/2843473002/ by machenbach@chromium.org.

The reason for reverting is: Breaks: 
https://build.chromium.org/p/client.v8/builders/V8%20Mac%20GC%20Stress/builds...
and
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20gc%20stress/....