I could reproduce this on Window's m50 stable, but not on Canary. Still looks something where we might want to consider a merge.

Oh look, a turbofan bug. Reproduced with branch-heads/5.0:

[...]

{"a":1.1}
{"a":1.1}
{"a":1.1}
{"a":1.1}
[marking 0x3200d6b1 <JS Function test (SharedFunctionInfo 0x2ba7e921)> for recompilation, reason: small function, ICs with typeinfo: 3/3 (100%), generic ICs: 0
/3 (0%)]
[didn't find optimized code in optimized code map for 0x2ba7e921 <SharedFunctionInfo test>]
[compiling method 0x3200d6b1 <JS Function test (SharedFunctionInfo 0x2ba7e921)> using TurboFan]
{"a":1.1}
{"a":1.1}
{"a":1.1}
{"a":1.1}
{"a":1.1}
{"a":1.1}
{"a":1.1}
{"a":1.1}
[optimizing 0x3200d6b1 <JS Function test (SharedFunctionInfo 0x2ba7e921)> - took 1.576, 0.000, 0.000 ms]
[didn't find optimized code in optimized code map for 0x2ba7e921 <SharedFunctionInfo test>]
[completed optimizing 0x3200d6b1 <JS Function test (SharedFunctionInfo 0x2ba7e921)>]
{"a":1.1}
{"a":0}
{"a":0}
{"a":0}
{"a":0}

[...]


Let me bisect when this was fixed.

The repro:

var test = function() {
  with ({}) {
    var o = { a: 1.1 };
    print(JSON.stringify(o));
  }
}
for (var i = 0; i < 1000; i++) test();

I bisected the fix to this:

commit b8229ec446b80fd3ff9a08362fe1cef36e9d8346
Author: bmeurer <bmeurer@chromium.org>
Date:   Tue May 10 03:11:06 2016 -0700

    [turbofan] Initial version of allocation folding and write barrier elimination.
    
    This adds a new pass MemoryOptimizer that walks over the effect chain
    from Start and lowers all Allocate, LoadField, StoreField, LoadElement,
    and StoreElement nodes, trying to fold allocations into allocation
    groups and eliminate write barriers on StoreField and StoreElement if
    possible (i.e. if the object belongs to the current allocation group and
    that group allocates in new space).
    
    R=hpayer@chromium.org, jarin@chromium.org
    BUG= v8:4931 ,  chromium:580959 
    LOG=n
    
    Review-Url: https://codereview.chromium.org/1963583004
    Cr-Commit-Position: refs/heads/master@{#36128}


For an outsider to Turbofan, I can't tell whether this actually fixes the issue or merely hides it. Can you verify? Also, what about back porting it to M50 and M51?

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/322ad66650aeca11989e684dc591e7261895ac03

commit 322ad66650aeca11989e684dc591e7261895ac03
Author: Benedikt Meurer <bmeurer@chromium.org>
Date: Thu May 12 11:58:33 2016

[turbofan] Properly initialize mutable heap numbers in literals.

We accidently drop the effect of the initializing store on the floor and
just hang on to the effect of the mutable heap number allocation. This
means that the store is actually dead code and will be trimmed from the
graph.

R=mstarzinger@chromium.org
BUG= chromium:610228 
NOPRESUBMIT=true
NOTRY=true
LOG=n

Review URL: https://codereview.chromium.org/1976553002 .

Cr-Commit-Position: refs/branch-heads/5.0@{#58}
Cr-Branched-From: ad16e6c2cbd2c6b0f2e8ff944ac245561c682ac2-refs/heads/5.0.71@{#1}
Cr-Branched-From: bd9df50d75125ee2ad37b3d92c8f50f0a8b5f030-refs/heads/master@{#34215}

[modify] https://crrev.com/322ad66650aeca11989e684dc591e7261895ac03/src/compiler/js-create-lowering.cc
[modify] https://crrev.com/322ad66650aeca11989e684dc591e7261895ac03/src/compiler/js-create-lowering.h
[add] https://crrev.com/322ad66650aeca11989e684dc591e7261895ac03/test/mjsunit/regress/regress-crbug-610228.js

We drop the effect of the initializing store on the floor, so it's eventually removed from the graph. Happens only on build w/o double field unboxing. Fixed on 5.0 and 5.1. Was already fixed on ToT by above mentioned commit.

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/0fce62b79df23c23ece9c33612249eab193d9ae0

commit 0fce62b79df23c23ece9c33612249eab193d9ae0
Author: bmeurer <bmeurer@chromium.org>
Date: Thu May 12 12:04:18 2016

[turbofan] Properly initialize mutable heap numbers in literals.

We accidently drop the effect of the initializing store on the floor and
just hang on to the effect of the mutable heap number allocation. This
means that the store is actually dead code and will be trimmed from the
graph.

R=mstarzinger@chromium.org
BUG= chromium:610228 
NOPRESUBMIT=true
NOTRY=true
LOG=n

Review-Url: https://codereview.chromium.org/1978453002
Cr-Commit-Position: refs/branch-heads/5.1@{#39}
Cr-Branched-From: 167dc63b4c9a1d0f0fe1b19af93644ac9a561e83-refs/heads/5.1.281@{#1}
Cr-Branched-From: 03953f52bd4a184983a551927c406be6489ef89b-refs/heads/master@{#35282}

[modify] https://crrev.com/0fce62b79df23c23ece9c33612249eab193d9ae0/src/compiler/js-create-lowering.cc
[modify] https://crrev.com/0fce62b79df23c23ece9c33612249eab193d9ae0/src/compiler/js-create-lowering.h
[add] https://crrev.com/0fce62b79df23c23ece9c33612249eab193d9ae0/test/mjsunit/regress/regress-crbug-610228.js

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform2/+/ef2dad89e3cd2e44dd3f67eda48d8e160757eeca

commit ef2dad89e3cd2e44dd3f67eda48d8e160757eeca
Author: Lutz Justen <ljusten@chromium.org>
Date: Thu Aug 31 09:37:07 2017

authpolicy: Support DeviceOffHours policy

Required for chromium:610228 in order to be able to uprev protofiles
to get the HTTP authentication policies.

CQ-DEPEND=CL:621007

BUG= chromium:610228 
TEST=cros_run_unit_tests --board=amd64-generic --packages "authpolicy"

Change-Id: Iabae22748538da12988ea40858e18f9448163840
Reviewed-on: https://chromium-review.googlesource.com/621086
Commit-Ready: Roman Sorokin <rsorokin@chromium.org>
Tested-by: Roman Sorokin <rsorokin@chromium.org>
Reviewed-by: Roman Sorokin <rsorokin@chromium.org>

[modify] https://crrev.com/ef2dad89e3cd2e44dd3f67eda48d8e160757eeca/authpolicy/policy/device_policy_encoder.cc
[modify] https://crrev.com/ef2dad89e3cd2e44dd3f67eda48d8e160757eeca/authpolicy/policy/device_policy_encoder_unittest.cc