If alignment parameter is set, the memory returned by the
StackSlot operator will be aligned according to the parameter.
The implementation goes like this. If alignment parameter is set
we allocate a bit more memory than actually needed and so we
can move the beginning of the StackSlot in order to have it aligned.
BUG=
Review-Url: https://codereview.chromium.org/2816743003
Cr-Commit-Position: refs/heads/master@{#45197}
That's cleaner than having every target depending on v8 include icu
itself.
BUG=none
R=machenbach@chromium.org
Change-Id: Icaa9e8670718664041a6efe2622366c89b733f81
Reviewed-on: https://chromium-review.googlesource.com/500127
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Jochen Eisinger <jochen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45196}
Reason for revert:
Original CL reverted.
Crashing on Canary
BUG=chromium:718891
Original issue's description:
> PPC/s390: Reland: [TypeFeedbackVector] Store optimized code in the vector
>
> Port 662aa425ba
>
> Original Commit Message:
>
> Since the feedback vector is itself a native context structure, why
> not store optimized code for a function in there rather than in
> a map from native context to code? This allows us to get rid of
> the optimized code map in the SharedFunctionInfo, saving a pointer,
> and making lookup of any optimized code quicker.
>
> Original patch by Michael Stanton <mvstanton@chromium.org>
>
> R=rmcilroy@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
> BUG=v8:6246
> LOG=N
>
> Review-Url: https://codereview.chromium.org/2861863003
> Cr-Commit-Position: refs/heads/master@{#45111}
> Committed: d587812258TBR=joransiu@ca.ibm.com,jyan@ca.ibm.com,michael_dawson@ca.ibm.com,rmcilroy@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=v8:6246
Review-Url: https://codereview.chromium.org/2870703003
Cr-Commit-Position: refs/heads/master@{#45195}
There's no point in using our own implemention of List for this.
Bug:v8:6333
Change-Id: Ic239c9348bb17d61e41130a18e1c9f16cab9d8ee
Reviewed-on: https://chromium-review.googlesource.com/489503
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45192}
This tests and fixes validation failures caused by assignments to
variables holding functions references (which are all considered
immutable). Such references can come from "stdlib" or "foreign".
R=clemensh@chromium.org
TEST=mjsunit/asm/global-imports
BUG=chromium:719382
Change-Id: Ic02be765e0773a6cc74a54e11a09d42ffb683cb8
Reviewed-on: https://chromium-review.googlesource.com/500188
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45189}
Before this fix, all existing suites would get wastefully initialized in each subprocess.
Bug: v8:6375
Change-Id: I68d961cde143754724735aecbac605852f89c7d9
Reviewed-on: https://chromium-review.googlesource.com/500187
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45188}
Before this, --print-bytecode flag was available in all Release builds
but did not actually print the bytecodes because OBJECT_PRINT is not set.
The output was pretty confusing:
[generating bytecode for function: ]
000002115442ABE9 <BytecodeArray[27]>[generating bytecode for function: main]
000002115442B069 <BytecodeArray[114]>[generating bytecode for function: Primes]
000002115442B729 <BytecodeArray[63]>[generating bytecode for function: Int32Array]
000002115442BB51 <BytecodeArray[175]>[generating bytecode for function: Primes.getPrimeCount]
000002115442BE81 <BytecodeArray[7]>[generating bytecode for function: Primes.isPrimeDivisible]
000002115442BFC9 <BytecodeArray[71]>[generating bytecode for function: Primes.addPrime]
000002115442C1C1 <BytecodeArray[31]>[generating bytecode for function: Primes.getPrime]
000002115442D7B1 <BytecodeArray[14]>
With this CL, --print-bytecode flag will always output bytecode, but
detailed info about constant pool and handler table are still guarded.
Bug:NO
Change-Id: Ie03be74520f45659303d1658da5b2acc02cf1b36
Reviewed-on: https://chromium-review.googlesource.com/497808
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Loo Rong Jie <loorongjie@gmail.com>
Cr-Commit-Position: refs/heads/master@{#45187}
Temporarily disable check for Etc/GMT and take it as well as
Etc/UTC until the root cause of crbug.com/719609 is found.
BUG=chromium:719609,v8:6252
TBR=adamk@chromium.org
Review-Url: https://codereview.chromium.org/2872873002
Cr-Commit-Position: refs/heads/master@{#45186}
Due to speculative optimizations, the compiler can run into situations
where it's asked perform impossible operations, like loading a tagged
element as a float64 instead. All of this is guaranteed to be in dead
code (unless there's a bug), but leads to confusion and violates
assumptions in the compiler (that make perfect sense for code that is
not dead). So teach LoadElimination not to mix up element accesses with
incompatible representations.
BUG=chromium:719479
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2866233002
Cr-Commit-Position: refs/heads/master@{#45185}
This is the next in the series of simplifying the logic to collect feedback
in compare bytecode handlers. An earlier cl (
https://chromium-review.googlesource.com/c/483399/) modified StrictEquals
bytecode handler. This cl inlines the type feedback collection for the
Equalbytecode handler.
Bug: v8:4280
Change-Id: I36210a2412bb84a3fdb982aabccf8cdefe87e30e
Reviewed-on: https://chromium-review.googlesource.com/498447
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45183}
This reverts commit 4fa473cb75.
Reason for revert: Problems when v8 isn't located in a folder called "v8".
Original change's description:
> [test] Don't flatten testcfg globals
>
> This loads each test's testcfg.py as a unique module rather than flattening all into testcfg. Other than accessing LoadTestSuite there should be no references into testcfg files.
>
> Bug: v8:6375
> Change-Id: If863c1b35096b2589111e8091bb7d68f135da674
> Reviewed-on: https://chromium-review.googlesource.com/498807
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Michael Achenbach <machenbach@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#45178}
TBR=jkummerow@chromium.org,machenbach@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Bug: v8:6375
Change-Id: I3600b54279c0d98a39475432c5b2163f510153f0
Reviewed-on: https://chromium-review.googlesource.com/500130
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45180}
This patch also makes concurrent marking visitor loads atomic.
BUG=chromium:694255
Review-Url: https://codereview.chromium.org/2872443003
Cr-Commit-Position: refs/heads/master@{#45179}
This loads each test's testcfg.py as a unique module rather than flattening all into testcfg. Other than accessing LoadTestSuite there should be no references into testcfg files.
Bug: v8:6375
Change-Id: If863c1b35096b2589111e8091bb7d68f135da674
Reviewed-on: https://chromium-review.googlesource.com/498807
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45178}
This CL prevents problems with library libicui18n.so during execution
inspector tests when component is defined as shared library.
TEST=inspector/*
BUG=
Review-Url: https://codereview.chromium.org/2863383003
Cr-Commit-Position: refs/heads/master@{#45176}
This reverts commit 662aa425ba.
Reason for revert: Crashing on Canary
BUG=chromium:718891
Original change's description:
> Reland: [TypeFeedbackVector] Store optimized code in the vector
>
> Since the feedback vector is itself a native context structure, why
> not store optimized code for a function in there rather than in
> a map from native context to code? This allows us to get rid of
> the optimized code map in the SharedFunctionInfo, saving a pointer,
> and making lookup of any optimized code quicker.
>
> Original patch by Michael Stanton <mvstanton@chromium.org>
>
> BUG=v8:6246
> TBR=yangguo@chromium.org,ulan@chromium.org
>
> Change-Id: Ic83e4011148164ef080c63215a0c77f1dfb7f327
> Reviewed-on: https://chromium-review.googlesource.com/494487
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#45084}
TBR=ulan@chromium.org,rmcilroy@chromium.org,yangguo@chromium.org,jarin@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
BUG=v8:6246
Change-Id: Idab648d6fe260862c2a0e35366df19dcecf13a82
Reviewed-on: https://chromium-review.googlesource.com/498633
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45174}
This reverts commit f7c25da680.
Reason for revert: Fixed
Original change's description:
> Revert "Introducing an event loop mechanism for d8."
>
> This reverts commit de964dbe57.
>
> Reason for revert:
> https://build.chromium.org/p/client.v8/builders/V8%20Linux/builds/17958
>
> Original change's description:
> > Introducing an event loop mechanism for d8.
> >
> > This mechanism ensures APIs like wasm async complete their work,
> > without requiring use of natives (%APIs).
> >
> > The mechanism is similar to the one used in content_shell,
> > which should allow us to easily port tests in that environment.
> >
> > Review-Url: https://codereview.chromium.org/2842843005
> > Cr-Original-Commit-Position: refs/heads/master@{#44908}
> > Bug:
> > Change-Id: I9deee0d256a600c60b42902fc8ef8478e5546344
> > Reviewed-on: https://chromium-review.googlesource.com/494968
> > Commit-Queue: Mircea Trofin <mtrofin@google.com>
> > Reviewed-by: Jochen Eisinger <jochen@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#45165}
>
> TBR=bradnelson@chromium.org,mtrofin@chromium.org,mtrofin@google.com,jochen@chromium.org
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
>
> Change-Id: Iafec2615d705d1990c57229cab3a988c00b5e12f
> Reviewed-on: https://chromium-review.googlesource.com/498630
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Commit-Queue: Michael Achenbach <machenbach@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#45166}
TBR=bradnelson@chromium.org,machenbach@chromium.org,mtrofin@chromium.org,mtrofin@google.com,jochen@chromium.org,v8-reviews@googlegroups.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: Ic3c782e918326e291a6cb9bb349c609e9a340b09
Reviewed-on: https://chromium-review.googlesource.com/498430
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Mircea Trofin <mtrofin@google.com>
Cr-Commit-Position: refs/heads/master@{#45172}
Intrinsic and generic lowering for generator object creation. In a follow-on, create lowering will be addressed.
BUG=v8:6352
Review-Url: https://codereview.chromium.org/2862213002
Cr-Commit-Position: refs/heads/master@{#45171}
This patch expands scope analysis to skip hole initialization
when it can be determined statically that no hole checks will
be generated at runtime.
Two conditions must be met to safely eliminate hole initialization:
- There must not exist a VariableProxy referencing this Variable
whose HoleCheckMode is kRequired
- The Variable must be stack allocated; any other allocation implies
that it may be accessed from not-yet-analyzed scopes (other modules,
inner functions, or eval code) and that code may require
hole checks.
The new logic required removing debug code in full-codegen which is
now incorrect in some cases.
Also fixed Variable's bitfield helpers to take no more space than needed.
Bug: chromium:651637
Change-Id: Ie5ac326af4e05b7a5c3c37cd4d0afba6a51a504d
Reviewed-on: https://chromium-review.googlesource.com/494006
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45170}
This reverts commit ec619cbd89.
Reason for revert: Crashing on Canary
BUG=chromium:718891
Original change's description:
> [Interpreter] Transition JSFunctions to call optimized code when possible.
>
> Now that the optimized code hangs off the feedback vector, it is possible
> to check whether a function has optimized code available every time it's
> called in the interpreter entry trampoline. If optimized code exists, the
> interpreter entry trampoline 'self-heals' the closure to point to the
> optimized code and links the closure into the optimized code list.
>
> BUG=v8:6246
>
> Change-Id: If1bd7c555bb0551bfe04b36baa6bcf949604717e
> Reviewed-on: https://chromium-review.googlesource.com/488026
> Reviewed-by: Michael Stanton <mvstanton@chromium.org>
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#45103}
TBR=rmcilroy@chromium.org,mvstanton@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
BUG=v8:6246
Change-Id: Ibda719be90fddf1d116c03a2a0c3018bcbe76018
Reviewed-on: https://chromium-review.googlesource.com/498632
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45169}
The code for UMA stats (in counters.h) is not thread safe, and can
lead to using pointers with uninitialized values.
Therefore, this CL turns them off when compiling asynchronously.
It also turns back on several UMA stats that were previously turned
off, but no longer need to because the code now knows if it is
running synchronously.
BUG=v8:6361
Review-Url: https://codereview.chromium.org/2864583004
Cr-Commit-Position: refs/heads/master@{#45168}
This reverts commit de964dbe57.
Reason for revert:
https://build.chromium.org/p/client.v8/builders/V8%20Linux/builds/17958
Original change's description:
> Introducing an event loop mechanism for d8.
>
> This mechanism ensures APIs like wasm async complete their work,
> without requiring use of natives (%APIs).
>
> The mechanism is similar to the one used in content_shell,
> which should allow us to easily port tests in that environment.
>
> Review-Url: https://codereview.chromium.org/2842843005
> Cr-Original-Commit-Position: refs/heads/master@{#44908}
> Bug:
> Change-Id: I9deee0d256a600c60b42902fc8ef8478e5546344
> Reviewed-on: https://chromium-review.googlesource.com/494968
> Commit-Queue: Mircea Trofin <mtrofin@google.com>
> Reviewed-by: Jochen Eisinger <jochen@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#45165}
TBR=bradnelson@chromium.org,mtrofin@chromium.org,mtrofin@google.com,jochen@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: Iafec2615d705d1990c57229cab3a988c00b5e12f
Reviewed-on: https://chromium-review.googlesource.com/498630
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45166}
This mechanism ensures APIs like wasm async complete their work,
without requiring use of natives (%APIs).
The mechanism is similar to the one used in content_shell,
which should allow us to easily port tests in that environment.
Review-Url: https://codereview.chromium.org/2842843005
Cr-Original-Commit-Position: refs/heads/master@{#44908}
Bug:
Change-Id: I9deee0d256a600c60b42902fc8ef8478e5546344
Reviewed-on: https://chromium-review.googlesource.com/494968
Commit-Queue: Mircea Trofin <mtrofin@google.com>
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45165}
Another fix for more explicit management of ownership. The
CompilationHelper now always owns the WasmModule, and transfers
ownership to the generated WasmModuleWrapper (a Managed<WasmModule>)
once that object is created. Since the stored uniqe_ptr cannot be
accessed any more after this transfer, the creation of the
WasmModuleWrapper is delayed until it is really needed (step 5 in async
compilation).
R=ahaas@chromium.org
Change-Id: I22dea2e14a364ddf76751d97bd0d736a4c0ceff4
Reviewed-on: https://chromium-review.googlesource.com/498507
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45164}
Reason for revert:
Should define its own NO_HARNESS_PATTERN. See comments.
Original issue's description:
> [test] add --no-harness option to debugger tests.
>
> Review-Url: https://codereview.chromium.org/2831083003
> Cr-Commit-Position: refs/heads/master@{#44774}
> Committed: 43c20d4cc5TBR=caitp@igalia.com,yangguo@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
Review-Url: https://codereview.chromium.org/2871593002
Cr-Commit-Position: refs/heads/master@{#45163}
Since the wasm module is verified before starting execution with lazy
compilation, the compilation of individual functions should not fail
later.
This CL changes the implementation to check this condition earlier
and removes unused error paths.
R=ahaas@chromium.org, mstarzinger@chromium.org
BUG=chromium:719286
Change-Id: If4bab457a47f214b457b2e2bc8570cba8c8bbcfd
Reviewed-on: https://chromium-review.googlesource.com/497755
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45161}
Make ModuleResult and FunctionResult return Result<std::unique_ptr<X>>.
This makes memory ownership and transfer of ownership more clear and
avoids a lot of manual releases of the referenced native heap object.
R=ahaas@chromium.org
Change-Id: I7a3f5bd7761b6ae1ebdc7d17ff1b96a8df599871
Reviewed-on: https://chromium-review.googlesource.com/498352
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45160}
We don't currently depend on this, but it might improve performance by
avoiding intermediate copies. The functions are already set up for
perfect forwarding, but without declaring the parameters as forwarding
references, this does not work as expected.
R=ahaas@chromium.org
Change-Id: I2c4d96ea1108b3f884d3e581e74c20aafd232934
Reviewed-on: https://chromium-review.googlesource.com/497409
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45158}
Inside the CompilationHelper, we were creating another compilation
helper to execute sequential or parallel compilation.
I don't see the reason to do so.
R=ahaas@chromium.org
Change-Id: Ib2c4486296a8f923e7e38620879c02963fff7d60
Reviewed-on: https://chromium-review.googlesource.com/497754
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45157}
With this CL we share code among the wasm fuzzers which construct a
module and run it in the interpreter and as compiled code.The fuzzers
themselves only contain the code now which creates the module and the
parameters.
BUG=v8:6325
R=eholk@chromium.org
Change-Id: I1c2d8b013531c86cb27837f1b8ec89d2688c536b
Reviewed-on: https://chromium-review.googlesource.com/490048
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45156}
It was replaced by more generic handling in 1320666798, which
is functionally fine, but for performance it makes sense to keep
the fast path.
Review-Url: https://codereview.chromium.org/2864463004
Cr-Commit-Position: refs/heads/master@{#45155}
Also make the macro name more scary, so people don't add new calls
BUG=v8:5830
R=jgruber@chromium.org
Change-Id: I06760110b7f0429d7775345b414c75c8df5e503a
Reviewed-on: https://chromium-review.googlesource.com/497451
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jochen Eisinger <jochen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45154}
In its destructor, the ErrorThrower already reifies exceptions and
throws them if an error has been set.
R=mtrofin@chromium.org
Change-Id: I17d7a6d300fe4a5860431f214746d053eaf9f104
Reviewed-on: https://chromium-review.googlesource.com/497467
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45153}
Bug:v8:5510
R=yangguo@chromium.org,jgruber@chromium.org
Change-Id: Ieb355110bd858efe2495a6271ffeda67d41af129
Reviewed-on: https://chromium-review.googlesource.com/497153
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Loo Rong Jie <loorongjie@gmail.com>
Cr-Commit-Position: refs/heads/master@{#45151}
History has shown that 99.93% (or more) of all memory allocations are less
than 1 megabyte, and they all appear in the same UMA stat entry.
To give perspective, the entry for <= 1Mb is about 20,000 times larger
than any other entry in the table. This makes the distribution in the
table hard to see.
And, for allocation failures at this size, the percentage of failures
(when compared to number of requests) is soo small (millions to one)
that little data can be gleamed from the <= 1Mb entry.
Note: requires CL https://codereview.chromium.org/2867483002
BUG=chrome:704922
R=bradnelson@chromium.org, bbudge@chromium.org, isherman@chromium.org
Review-Url: https://codereview.chromium.org/2856663002
Cr-Commit-Position: refs/heads/master@{#45148}
