The cells are stored on prototypes (in their map's PrototypeInfo). When a prototype object changes its map, then both its own validity cell and those of all "downstream" prototypes are invalidated; handlers for a given receiver embed the currently valid cell for that receiver's prototype during their compilation and check it on execution.
Review URL: https://codereview.chromium.org/908213002
Cr-Commit-Position: refs/heads/master@{#27845}
- ConstantOperand was using a too-small field too store its virtual register
- drop ConvertTo, replace it with simple copy
- split AllocatedOperand off from Immediate and Constant to make assignment clearer, also paving the way for small Immediates
- put zone first in *Operand::New
- driveby: drop delayed ssa deconstruction experiment
R=titzer@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1050803002
Cr-Commit-Position: refs/heads/master@{#27692}
Reason for revert:
this indeed drops the max major gc time considerable, so turn it back on
Original issue's description:
> Turn off overapproximation of the weak closure again
>
> As long as we still have to process global handles, the impact is not
> yet worthwhile
>
> BUG=v8:3862
> R=hpayer@chromium.org
> LOG=y
>
> Committed: https://crrev.com/294cdc6aecbd7f76be68217da4b3d35901ebce4b
> Cr-Commit-Position: refs/heads/master@{#27570}
TBR=hpayer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:3862
Review URL: https://codereview.chromium.org/1068723003
Cr-Commit-Position: refs/heads/master@{#27616}
Reason for revert:
Reverting risky GC changes that block v8 roll.
Original issue's description:
> Reland "Filter invalid slots out from the SlotsBuffer after marking."
>
> > There are two reasons that could cause invalid slots appearance in SlotsBuffer:
> > 1) If GC trims "tail" of an array for which it has already recorded a slots and then migrate another object to the "tail".
> > 2) Tagged slot could become a double slot after migrating of an object to another map with "shifted" fields (for example as a result of generalizing immutable data property to a data field).
>
> > This CL also adds useful machinery that helps triggering incremental write barriers.
>
> > BUG=chromium:454297
> > LOG=Y
>
> NOTRY=true
>
> Committed: https://crrev.com/f86aadd1d45c756467dff8e08a055b462d7a060b
> Cr-Commit-Position: refs/heads/master@{#27433}
TBR=machenbach@chromium.org,ulan@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1041593002
Cr-Commit-Position: refs/heads/master@{#27491}
> There are two reasons that could cause invalid slots appearance in SlotsBuffer:
> 1) If GC trims "tail" of an array for which it has already recorded a slots and then migrate another object to the "tail".
> 2) Tagged slot could become a double slot after migrating of an object to another map with "shifted" fields (for example as a result of generalizing immutable data property to a data field).
> This CL also adds useful machinery that helps triggering incremental write barriers.
> BUG=chromium:454297
> LOG=Y
NOTRY=true
Review URL: https://codereview.chromium.org/1032833002
Cr-Commit-Position: refs/heads/master@{#27433}
Reason for revert:
Need to revert in order to revert https://codereview.chromium.org/1029323003/
Original issue's description:
> Filter invalid slots out from the SlotsBuffer after marking.
>
> There are two reasons that could cause invalid slots appearance in SlotsBuffer:
> 1) If GC trims "tail" of an array for which it has already recorded a slots and then migrate another object to the "tail".
> 2) Tagged slot could become a double slot after migrating of an object to another map with "shifted" fields (for example as a result of generalizing immutable data property to a data field).
>
> This CL also adds useful machinery that helps triggering incremental write barriers.
>
> BUG=chromium:454297
> LOG=Y
>
> Committed: https://crrev.com/5c47c1c0d3e4a488f190c16a64ee02f5a14e6561
> Cr-Commit-Position: refs/heads/master@{#27423}
TBR=hpayer@chromium.org,erik.corry@gmail.com,ishell@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:454297
Review URL: https://codereview.chromium.org/1033453005
Cr-Commit-Position: refs/heads/master@{#27426}
There are two reasons that could cause invalid slots appearance in SlotsBuffer:
1) If GC trims "tail" of an array for which it has already recorded a slots and then migrate another object to the "tail".
2) Tagged slot could become a double slot after migrating of an object to another map with "shifted" fields (for example as a result of generalizing immutable data property to a data field).
This CL also adds useful machinery that helps triggering incremental write barriers.
BUG=chromium:454297
LOG=Y
Review URL: https://codereview.chromium.org/1010363005
Cr-Commit-Position: refs/heads/master@{#27423}
This change introduces a liveness analyzer for local variables in frame states.
The main idea is to use the AstGraphBuilder::Environment class to build the control flow graph, and record local variable loads, stores and checkpoints in the CFG basic blocks (LivenessAnalyzerBlock class).
After the graph building finishes, we run a simple data flow analysis over the CFG to figure out liveness of each local variable at each checkpoint. Finally, we run a pass over all the checkpoints and replace dead local variables in the frame states with the 'undefined' value.
Performance numbers for Embenchen are below.
----------- box2d.js
Current --turbo-deoptimization: EmbenchenBox2d(RunTime): 11265 ms.
d8-master --turbo-deoptimization: EmbenchenBox2d(RunTime): 11768 ms.
d8-master: EmbenchenBox2d(RunTime): 10996 ms.
----------- bullet.js
Current --turbo-deoptimization: EmbenchenBullet(RunTime): 17049 ms.
d8-master --turbo-deoptimization: EmbenchenBullet(RunTime): 17384 ms.
d8-master: EmbenchenBullet(RunTime): 16153 ms.
----------- copy.js
Current --turbo-deoptimization: EmbenchenCopy(RunTime): 4877 ms.
d8-master --turbo-deoptimization: EmbenchenCopy(RunTime): 4938 ms.
d8-master: EmbenchenCopy(RunTime): 4940 ms.
----------- corrections.js
Current --turbo-deoptimization: EmbenchenCorrections(RunTime): 7068 ms.
d8-master --turbo-deoptimization: EmbenchenCorrections(RunTime): 6718 ms.
d8-master: EmbenchenCorrections(RunTime): 6858 ms.
----------- fannkuch.js
Current --turbo-deoptimization: EmbenchenFannkuch(RunTime): 4167 ms.
d8-master --turbo-deoptimization: EmbenchenFannkuch(RunTime): 4608 ms.
d8-master: EmbenchenFannkuch(RunTime): 4149 ms.
----------- fasta.js
Current --turbo-deoptimization: EmbenchenFasta(RunTime): 9981 ms.
d8-master --turbo-deoptimization: EmbenchenFasta(RunTime): 9848 ms.
d8-master: EmbenchenFasta(RunTime): 9640 ms.
----------- lua_binarytrees.js
Current --turbo-deoptimization: EmbenchenLuaBinaryTrees(RunTime): 11571 ms.
d8-master --turbo-deoptimization: EmbenchenLuaBinaryTrees(RunTime): 13089 ms.
d8-master: EmbenchenLuaBinaryTrees(RunTime): 10957 ms.
----------- memops.js
Current --turbo-deoptimization: EmbenchenMemOps(RunTime): 7766 ms.
d8-master --turbo-deoptimization: EmbenchenMemOps(RunTime): 7346 ms.
d8-master: EmbenchenMemOps(RunTime): 7738 ms.
----------- primes.js
Current --turbo-deoptimization: EmbenchenPrimes(RunTime): 7459 ms.
d8-master --turbo-deoptimization: EmbenchenPrimes(RunTime): 7453 ms.
d8-master: EmbenchenPrimes(RunTime): 7451 ms.
----------- skinning.js
Current --turbo-deoptimization: EmbenchenSkinning(RunTime): 15564 ms.
d8-master --turbo-deoptimization: EmbenchenSkinning(RunTime): 15611 ms.
d8-master: EmbenchenSkinning(RunTime): 15583 ms.
----------- zlib.js
Current --turbo-deoptimization: EmbenchenZLib(RunTime): 10825 ms.
d8-master --turbo-deoptimization: EmbenchenZLib(RunTime): 11180 ms.
d8-master: EmbenchenZLib(RunTime): 10823 ms.
BUG=
Review URL: https://codereview.chromium.org/949743002
Cr-Commit-Position: refs/heads/master@{#27232}
Reason for revert:
Increased rate of Chrome crashes. Requires further investigation.
Original issue's description:
> Reland of Remove slots that point to unboxed doubles from the StoreBuffer/SlotsBuffer.
>
> The problem is that tagged slot could become a double slot after migrating of an object to another map with "shifted" fields (for example as a result of generalizing immutable data property to a data field).
> This CL also adds useful machinery that helps triggering incremental write barriers.
>
> BUG=chromium:454297, chromium:465273
> LOG=Y
>
> Committed: https://crrev.com/6d0677d845c47ab9fa297de61d0e3d8e5480a02a
> Cr-Commit-Position: refs/heads/master@{#27141}
TBR=hpayer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:454297, chromium:465273
Review URL: https://codereview.chromium.org/1004623003
Cr-Commit-Position: refs/heads/master@{#27207}
The problem is that tagged slot could become a double slot after migrating of an object to another map with "shifted" fields (for example as a result of generalizing immutable data property to a data field).
This CL also adds useful machinery that helps triggering incremental write barriers.
BUG=chromium:454297, chromium:465273
LOG=Y
Review URL: https://codereview.chromium.org/988363002
Cr-Commit-Position: refs/heads/master@{#27141}
The JSInliner used to load the context from the JSFunction node at
runtime, which introduced a HeapConstant (because we had to materialize
the JSFunction after context specialization) and a LoadField operation,
independent whether the inlinee actually uses the context. This is
rather cumbersome currently, and therefore this is now changed to just
embed the context constant instead. Once we do inlining based on
SharedFunctionInfo rather than JSFunction, we should reconsider this
decision and come up with a proper heuristic.
BUG=v8:3952
LOG=n
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/994523002
Cr-Commit-Position: refs/heads/master@{#27069}
Reason for revert:
It caused a lot of Canary crashes.
Original issue's description:
> Remove slots that point to unboxed doubles from the StoreBuffer/SlotsBuffer.
>
> The problem is that tagged slot could become a double slot after migrating of an object to another map with "shifted" fields (for example as a result of generalizing immutable data property to a data field).
> This CL also adds useful machinery that helps triggering incremental write barriers.
>
> BUG=chromium:454297
> LOG=Y
>
> Committed: https://crrev.com/9633ebabd405c264d33f603f8798c31f59418dcd
> Cr-Commit-Position: refs/heads/master@{#27054}
TBR=verwaest@chromium.org,hpayer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:454297
Review URL: https://codereview.chromium.org/991793002
Cr-Commit-Position: refs/heads/master@{#27063}
We mark certain builtins for inlining, and those should always be
inlined into optimized code (CrankShaft already handles it this way), so
we should support that in TurboFan as well. Currently this mainly
affects a certain set of Math functions, but once have the basics in
place we can extend this to any kind of builtin/code stub/accessor.
This adds a new flag --turbo_builtin_inlining (enabled by default), that
forces the inliner to always inline builtins marked for inlining, but
does not affect inlining of other functions (this is still controlled by
the --turbo-inlining flag).
BUG=v8:3952
LOG=n
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/993473002
Cr-Commit-Position: refs/heads/master@{#27059}
The problem is that tagged slot could become a double slot after migrating of an object to another map with "shifted" fields (for example as a result of generalizing immutable data property to a data field).
This CL also adds useful machinery that helps triggering incremental write barriers.
BUG=chromium:454297
LOG=Y
Review URL: https://codereview.chromium.org/957273002
Cr-Commit-Position: refs/heads/master@{#27054}
This keeps dying maps alive for FLAG_retain_maps_for_n_gc garbage collections
to increase chances of them being reused for new objects in future and
decrease number of deoptimizations.
BUG=v8:3664
LOG=N
TEST=cctest/test-heap/MapRetaining
Review URL: https://codereview.chromium.org/980523004
Cr-Commit-Position: refs/heads/master@{#27040}