This CL introduces a small struct to hold the {mem_start} and {mem_size}
node pointers that are managed in the function body decoder's SSA environment.
This struct insulates the function body decoder from further changes in
how context-specific information is represented in the compiler.
R=clemensh@chromium.org
CC=mstarzinger@chromium.org
Bug:
Change-Id: If17bef9fd2490ac11e4f3b3614f91333bb0b9528
Reviewed-on: https://chromium-review.googlesource.com/817282
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Ben L. Titzer <titzer@google.com>
Cr-Commit-Position: refs/heads/master@{#50004}
Straight forward bug - we took a naked pointer after which we
perform an allocation.
Bug: chromium:793671
Change-Id: I0cebd606c31edaca27abedc19bc878204eb9a18b
Reviewed-on: https://chromium-review.googlesource.com/818634
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50003}
This reverts commit 1e49864fa7.
Reason for revert: Crashing test on the waterfall https://logs.chromium.org/v/?s=chromium%2Fbb%2Fclient.v8%2FV8_Linux_gcc_4.8%2F16871%2F%2B%2Frecipes%2Fsteps%2FCheck%2F0%2Flogs%2FReturnMultipleRandom%2F0
Original change's description:
> [turbofan] Implement on-stack returns (Intel)
>
> Add the ability to return (multiple) return values on the stack:
>
> - Extend stack frames with a new buffer region for return slots.
> This region is located at the end of a caller's frame such that
> its slots can be indexed as caller frame slots in a callee
> (located beyond its parameters) and assigned return values.
> - Adjust stack frame constructon and deconstruction accordingly.
> - Extend linkage computation to support register plus stack returns.
> - Reserve return slots in caller frame when respective calls occur.
> - Introduce and generate architecture instructions ('peek') for
> reading back results from return slots in the caller.
> - Aggressive tests.
> - Some minor clean-up.
>
> So far, only ia32 and x64 are implemented.
>
> Change-Id: I9532ad13aa307c1dec40548c5b84600fe2f762ce
> Reviewed-on: https://chromium-review.googlesource.com/766371
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49994}
TBR=titzer@chromium.org,rossberg@chromium.org,ahaas@chromium.org
Change-Id: Ib257e92448942f8ef07d5ef246f9381f4784f014
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/819637
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50000}
Also put an UNREACHABLE into an impossible case in
NumberOpFromSpeculativeNumberOp.
R=jarin@chromium.org
Bug:
Change-Id: I681b7bc58de5038497667cb48fdcd79a73abe1c2
Reviewed-on: https://chromium-review.googlesource.com/819415
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49998}
The parser holds a single vector whose backing storage is reused in calls
to ParseJsonObject, so that once we reach the peak number of unstored
properties no more allocations are required.
This improves performance of parsing inputs like those in Speedometer VanillaJS
by about 2% in my local measurement, and would presumably do better on more
pathological inputs.
This should also have the side effect of reducing peak memory usage at this time
slightly, since we do fewer zone allocations which cannot be freed until the
parse finishes.
Reland switches to use std::vector::data instead of operator[] to avoid an index
check in debug MSVC. In such cases the out-of-bounds pointer cannot be
dereferenced, so it is legal.
Bug: chromium:771227
Change-Id: I21837196372c904bfc799cd14353a73d11dcff32
Reviewed-on: https://chromium-review.googlesource.com/804062
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Jeremy Roman <jbroman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49997}
We have to ensure that replacements do not have replacements because
otherwise a changed replacement (of the replacement) wouldn't trigger
graph revisitations. However, this invariant can be temporarily
violated when the information propagated along the effect chain is
outdated for another reason. So we should only check this for the final
fixed-point.
Bug: chromium:787959
Change-Id: I4a6b2c4f6ff3205649c0f866654900d4ab126acf
Reviewed-on: https://chromium-review.googlesource.com/817777
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49995}
Add the ability to return (multiple) return values on the stack:
- Extend stack frames with a new buffer region for return slots.
This region is located at the end of a caller's frame such that
its slots can be indexed as caller frame slots in a callee
(located beyond its parameters) and assigned return values.
- Adjust stack frame constructon and deconstruction accordingly.
- Extend linkage computation to support register plus stack returns.
- Reserve return slots in caller frame when respective calls occur.
- Introduce and generate architecture instructions ('peek') for
reading back results from return slots in the caller.
- Aggressive tests.
- Some minor clean-up.
So far, only ia32 and x64 are implemented.
Change-Id: I9532ad13aa307c1dec40548c5b84600fe2f762ce
Reviewed-on: https://chromium-review.googlesource.com/766371
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49994}
Moving a register to itself is not only unnecessary overhead, it also
breaks invariants in the StackTransferRecipe.
R=ahaas@chromium.org
Bug: v8:6600, chromium:793551
Change-Id: I659fd66b4f2d4564c437ed9fb048322af4299d97
Reviewed-on: https://chromium-review.googlesource.com/819231
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49992}
Explain why we still have kNumber in addition to kNumberOrOddball,
although the original motivation, which was Crankshaft, is gone now.
Bug: v8:7109
Change-Id: I33016fbfa96bb0db57473b6d0c720fa1389d11f1
Reviewed-on: https://chromium-review.googlesource.com/817439
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49991}
The CompareOperationFeedback documentation was outdated and there was an
invalid TODO on it that suggested to unify this with the
BinaryOperationFeedback which in retrospect doesn't make a lot of sense.
Bug: v8:7109
Change-Id: Ibf748e242db55430f29d305f1ef1df6d44449481
Reviewed-on: https://chromium-review.googlesource.com/819090
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49990}
This helps to debug issues with maintaining the cache state, and also
understanding errors in the generated code.
Unfortunately, it requires buffering the trace output in the decoder,
since the interface is called in between, and the output would be
messed up otherwise.
R=titzer@chromium.org
Bug: v8:6600
Change-Id: Ie8af8f7f619f3909ea52268241b883a4d4de79fa
Reviewed-on: https://chromium-review.googlesource.com/813972
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49989}
For the JS object allocation case, we materialize children_count - 1 objects.
However, we already materialized the map and property array, so this could
materialize one object beyond the JS object. If there is no such object,
we would go out-of-bounds.
Bug: chromium:792330
Change-Id: I5ed5e4ddde9de9789bb2531a48a0d87c80bd156c
Reviewed-on: https://chromium-review.googlesource.com/817315
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49986}
This xor can never change the number of collisions, so it should be safe to remove.
Bug:
Change-Id: I253c0ece422f66e7cba15b13c041cfb6c8361674
Reviewed-on: https://chromium-review.googlesource.com/809113
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49985}
This relands commit e71b802279.
This can now back in as the fix for chromium:787301 had enough time to
be tested in Canary.
Original change's description:
> [deoptimizer] Staged materialization of objects.
>
> The existing object materialization in the deoptimizer has the following problems:
>
> - Objects do not necessarily verify during materialization (because during the
> depth first walk we might have inconsistent objects).
>
> - Stack can overflow (because we just materialize using recursive calls).
>
> - We generalize object fields.
>
>
> This CL re-implements the materialization algorithm to solve this problem. The
> new implementation creates the objects in two steps:
>
> 1. We allocate space for all the objects. In general, we allocate ByteArrays
> of the right size. For leaf objects that cannot participate in cycles,
> we build and initialize the materialized objects completely.
>
> For JS objects, we insert markers into the byte array at the positions
> where unboxed doubles are expected.
>
> 2. We initialize all the objects with the proper field values and change the
> map from the ByteArray map to the correct map. This requires some sync
> with the concurrent marker (Heap::NotifyObjectLayoutChange).
>
> When initializing the JS object fields, we make sure that we respect
> the unboxed double marker.
>
> Bug: chromium:770106, v8:3836
> Change-Id: I1ec466a9d19db9538df4ba915516d4c3ca825632
> Reviewed-on: https://chromium-review.googlesource.com/777559
> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49821}
Bug: chromium:770106, v8:3836
Change-Id: Ied6c4e0fbae52713e55ae6dc13794a7521dbb8a5
Reviewed-on: https://chromium-review.googlesource.com/817745
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49982}
If the source checkout had 'debug' somewhere in the path name, then
IsDebuggerFile() marked all modules as debug ones, which triggered
an assertion during snapshot generation.
Bug:
Change-Id: I93537efca9152c5469bb760f32ca53b06351f7a4
Reviewed-on: https://chromium-review.googlesource.com/809205
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49980}
await expressions are an invalid destructuring target, and should
result in a SyntaxError when used in a position where a destructuring
target is expected.
BUG=v8:7173
R=marja@chromium.org, adamk@chromium.org
Change-Id: I1bdb4bc13cb2e3e904fc4389a6e0abca1e0ed17f
Reviewed-on: https://chromium-review.googlesource.com/811946
Reviewed-by: Sathya Gunasekaran (ooo until 12/12) <gsathya@chromium.org>
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#49977}
NewSpace::UpdateInlineAllocationLimit was computing the limit slighly
differently. Make old space and new space more consistent. The way
new space does it makes more sense as, logically, the step starts from
beyond the current object being allocated (size_in_bytes).
This behaviour change in preperation for a subsequent CL that refactors
a common SpaceWithLinearArea::ComputeLimit.
NewSpace: :UpdateInlineAllocationLimit and PagedSpace::ComputeLimit into
Change-Id: Ibe918d46dccf8e80ed35c770b3c365c3970d07ea
Reviewed-on: https://chromium-review.googlesource.com/815277
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ali Ijaz Sheikh <ofrobots@google.com>
Cr-Commit-Position: refs/heads/master@{#49974}
- Changes d8 ArrayBuffer::Allocators to restrict size to < 2GB on the
Allocate/AllocateUninitialized paths. Reserve can still create larger
ArrayBuffers.
Bug: chromium:793196
Change-Id: I662f8c681f715457d630df31039a1ea4d17cfafc
Reviewed-on: https://chromium-review.googlesource.com/817763
Commit-Queue: Bill Budge <bbudge@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49973}
If the fixed array is being concurrently left-trimmed then checked
getter can assert because the length is not necessarily a Smi.
This patch uses unchecked length getter to cache the length as Object*.
Only if the marker manages to color the array black, we are guaranteed
that the cached length is a Smi.
This patch also uses unchecked cast for FixedArray in HeapVisitor
for concurrent marker.
Note that this patch only affects debug mode.
Bug: chromium:694255
Change-Id: I5016a2234a9f5fb98b498e06f5d1428b3f1cc3c6
Reviewed-on: https://chromium-review.googlesource.com/817554
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49970}
- Introduce explicit CallXXX helpers in PropertyCallbackArguments for
all Callback functions exposed in the api.
- Add bit on the Interceptors for checking whether they for names or
indices.
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Id862e4e39ba75b4610156adfe83f3eecfb2c048f
Reviewed-on: https://chromium-review.googlesource.com/799910
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49969}
I also adjusted the update script because the output directory of the
run.py script we call has changed.
R=clemensh#chromium.org
Change-Id: I432c81f1a2ffd3c96a294f771064672f7edad250
Reviewed-on: https://chromium-review.googlesource.com/817275
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49968}
This is a prepratory change to allow more refactoring of code between
New and PagedSpace.
Bug:
Change-Id: Iabda8365cae0de2278d772e56728e900e688c9aa
Reviewed-on: https://chromium-review.googlesource.com/815904
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ali Ijaz Sheikh <ofrobots@google.com>
Cr-Commit-Position: refs/heads/master@{#49966}
This patch adds a field for the speculation mode to Call
nodes, and passes the speculation mode from the CallIC
to the Call node in the byte code graph builder.
Bug: v8:7127
Change-Id: I89fa10643b46143b36776de1d5ba6ebe3fa2c878
Reviewed-on: https://chromium-review.googlesource.com/814537
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49965}
This moves the verify-predictable logic from the test runner into
a python wrapper script.
This revealed two more tests that don't print allocations, which are
now skipped.
Bug: v8:7166, v8:7177
Change-Id: Ie4a541cb2a20900414ffe1caf4b3fccc4a5edb52
Reviewed-on: https://chromium-review.googlesource.com/808971
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Sergiy Byelozyorov <sergiyb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49964}
This reverts commit 1081720532.
While increasing the number of IRREGEXP regexp instances (vs. ATOM)
gives us a 3% perf improvement, it also results in higher memory
overhead. This CL is the suspected culprit for the recent 5x increase
in OOM crashes from within regexp codegen.
Bug: v8:6633, chromium:790833
Change-Id: Icca70b31fbda8cfb7a63dc895f6665dfe534359d
Reviewed-on: https://chromium-review.googlesource.com/817294
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49963}
Some buildbots were not compiling due to error `chosen constructor
is explicit in copy-initialization`
Bug:
Change-Id: I24b8f1c4467e05e2832d8252a4cfe7352e1e91da
Reviewed-on: https://chromium-review.googlesource.com/813758
Commit-Queue: Ivica Bogosavljevic <ivica.bogosavljevic@mips.com>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49962}
Port 2cbfa2444d
Original Commit Message:
[Memory] Use madvise on POSIX to allow OS to reclaim memory.
- Use madvise when setting no permissions on memory.
- Move platform specific mmap flag calculations to a helper fn.
Bug: chromium:756050,chromium:788341
Change-Id: I7d420a0abee9656a57fb0317301322da2fd7d7b5
Reviewed-on: https://chromium-review.googlesource.com/790932
Change-Id: I5f7957066d0be96bd429b3d55c9293ffb996750c
Reviewed-on: https://chromium-review.googlesource.com/804554
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49961}
This CL uses bits of the call count as flags according
to CallCountField and SpeculationModeField defined in
CallICNexus.
Bug: v8:7127
Change-Id: I3f64c1807d61410f9029b46b9a59a1fcaa5a0a3b
Reviewed-on: https://chromium-review.googlesource.com/808926
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49959}
This separates common logic that applies to both coverage/type profiling
(i.e. collecting feedback vectors into the list) from work that's only
required by coverage (resetting SFI::has_reported_binary_coverage and
FeedbackVector::invocation_count).
Bug: v8:6000
Change-Id: Icb36a8a6af34b3a425814d69653e331ca8f76cd5
Reviewed-on: https://chromium-review.googlesource.com/813922
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Franziska Hinkelmann <franzih@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49956}
