Skip to content

V
V8
Switch branch/tag
  1. 08 Aug, 2018 1 commit
    • Junliang Yan's avatar
      PPC/s390: Reland "[turboassembler] Introduce hard-abort mode" · a27871d5
      Junliang Yan authored 
      Port d324382e

and

Port bd3f0a68

Original Commit Message:

    This is a reland of a462a785

    Original change's description:
    > [turboassembler] Introduce hard-abort mode
    >
    > For checks and assertions (mostly for debug code, like stack alignment
    > or zero extension), we had two modes: Emit a call to the {Abort}
    > runtime function (the default), and emit a debug break (used for
    > testing, enabled via --trap-on-abort).
    > In wasm, where we cannot just call a runtime function because code must
    > be isolate independent, we always used the trap-on-abort behaviour.
    > This causes problems for our fuzzers, which do not catch SIGTRAP, and
    > hence do not detect debug code failures.
    >
    > This CL introduces a third mode ("hard abort"), which calls a C
    > function via {ExternalReference}. The C function still outputs the
    > abort reason, but does not print the stack trace. It then aborts via
    > "OS::Abort", just like the runtime function.
    > This will allow fuzzers to detect the crash and even find a nice error
    > message.
    >
    > Even though this looks like a lot of code churn, it is actually not.
    > Most added lines are new tests, and other changes are minimal.
    >
    > R=mstarzinger@chromium.org
    >
    > Bug: chromium:863799
    > Change-Id: I77c58ff72db552d49014614436259ccfb49ba87b
    > Reviewed-on: https://chromium-review.googlesource.com/1142163
    > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
    > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
    > Cr-Commit-Position: refs/heads/master@{#54592}

R=clemensh@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N

Change-Id: I60023470fa07576fd313f628ade06e279d5f4927
Reviewed-on: https://chromium-review.googlesource.com/1165822
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54980}
      a27871d5
  3. 24 Jul, 2018 2 commits
    • Clemens Hammacher's avatar
      Reland "[turboassembler] Introduce hard-abort mode" · d324382e
      Clemens Hammacher authored 
      This is a reland of a462a785

Original change's description:
> [turboassembler] Introduce hard-abort mode
> 
> For checks and assertions (mostly for debug code, like stack alignment
> or zero extension), we had two modes: Emit a call to the {Abort}
> runtime function (the default), and emit a debug break (used for
> testing, enabled via --trap-on-abort).
> In wasm, where we cannot just call a runtime function because code must
> be isolate independent, we always used the trap-on-abort behaviour.
> This causes problems for our fuzzers, which do not catch SIGTRAP, and
> hence do not detect debug code failures.
> 
> This CL introduces a third mode ("hard abort"), which calls a C
> function via {ExternalReference}. The C function still outputs the
> abort reason, but does not print the stack trace. It then aborts via
> "OS::Abort", just like the runtime function.
> This will allow fuzzers to detect the crash and even find a nice error
> message.
> 
> Even though this looks like a lot of code churn, it is actually not.
> Most added lines are new tests, and other changes are minimal.
> 
> R=mstarzinger@chromium.org
> 
> Bug: chromium:863799
> Change-Id: I77c58ff72db552d49014614436259ccfb49ba87b
> Reviewed-on: https://chromium-review.googlesource.com/1142163
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#54592}

Bug: chromium:863799
Change-Id: I7729a47b4823a982a8e201df36520aa2b6ef5326
Reviewed-on: https://chromium-review.googlesource.com/1146100Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54656}
      d324382e
    • Tobias Tebbi's avatar
      [torque] add unittest for Earley parser · f31c6419
      Tobias Tebbi authored 
      Change-Id: I02c117ef66480eb73eb9cc1d4f80bbc64e9d3624
Reviewed-on: https://chromium-review.googlesource.com/1146655
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54649}
      f31c6419
  5. 20 Jul, 2018 2 commits
    • Sigurd Schneider's avatar
      Speculatively revert "[turboassembler] Introduce hard-abort mode" · 039c18e1
      Sigurd Schneider authored 
      This reverts commit a462a785.

Reason for revert: Breaks a TurboAssembler test:
https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Arm/7726

Original change's description:
> [turboassembler] Introduce hard-abort mode
> 
> For checks and assertions (mostly for debug code, like stack alignment
> or zero extension), we had two modes: Emit a call to the {Abort}
> runtime function (the default), and emit a debug break (used for
> testing, enabled via --trap-on-abort).
> In wasm, where we cannot just call a runtime function because code must
> be isolate independent, we always used the trap-on-abort behaviour.
> This causes problems for our fuzzers, which do not catch SIGTRAP, and
> hence do not detect debug code failures.
> 
> This CL introduces a third mode ("hard abort"), which calls a C
> function via {ExternalReference}. The C function still outputs the
> abort reason, but does not print the stack trace. It then aborts via
> "OS::Abort", just like the runtime function.
> This will allow fuzzers to detect the crash and even find a nice error
> message.
> 
> Even though this looks like a lot of code churn, it is actually not.
> Most added lines are new tests, and other changes are minimal.
> 
> R=​mstarzinger@chromium.org
> 
> Bug: chromium:863799
> Change-Id: I77c58ff72db552d49014614436259ccfb49ba87b
> Reviewed-on: https://chromium-review.googlesource.com/1142163
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#54592}

TBR=mstarzinger@chromium.org,clemensh@chromium.org

Change-Id: I60c011cfe262ccebbb9abf32699a9fe17e72a3c8
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:863799
Reviewed-on: https://chromium-review.googlesource.com/1145431
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54597}
      039c18e1
    • Clemens Hammacher's avatar
      [turboassembler] Introduce hard-abort mode · a462a785
      Clemens Hammacher authored 
      For checks and assertions (mostly for debug code, like stack alignment
or zero extension), we had two modes: Emit a call to the {Abort}
runtime function (the default), and emit a debug break (used for
testing, enabled via --trap-on-abort).
In wasm, where we cannot just call a runtime function because code must
be isolate independent, we always used the trap-on-abort behaviour.
This causes problems for our fuzzers, which do not catch SIGTRAP, and
hence do not detect debug code failures.

This CL introduces a third mode ("hard abort"), which calls a C
function via {ExternalReference}. The C function still outputs the
abort reason, but does not print the stack trace. It then aborts via
"OS::Abort", just like the runtime function.
This will allow fuzzers to detect the crash and even find a nice error
message.

Even though this looks like a lot of code churn, it is actually not.
Most added lines are new tests, and other changes are minimal.

R=mstarzinger@chromium.org

Bug: chromium:863799
Change-Id: I77c58ff72db552d49014614436259ccfb49ba87b
Reviewed-on: https://chromium-review.googlesource.com/1142163
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54592}
      a462a785
  7. 07 Jun, 2018 1 commit
  9. 04 Jun, 2018 1 commit
  11. 22 May, 2018 1 commit
  13. 08 May, 2018 1 commit
    • Jaroslav Sevcik's avatar
      [turbofan] Optimize array destructuring · 3fe7d698
      Jaroslav Sevcik authored 
      This CL introduces type narrowing and constant folding reducers
to constant fold code that comes out of inlined destructuring
of arrays. In particular, array iterator introduces code that
contains a phi of a temporary array that blocks escape analysis.
The phi comes from conditional that can be evaluated statically
(i.e., constant folded), so with better constant folding we
allow escape analysis to get rid of the temporary array.

On a quick micro-benchmark below, we see more than 6x improvement.
This is close to the hand-optimized version - if we replace
body of f with 'return b + a', we get 220ms (versus 218ms with
destructuring).

function f(a, b) {
  [b, a] = [a, b];
  return a + b;
}

function sum(count) {
  let s = 0;
  for (let i = 0; i < count; i++) {
    s += f(1, 2);
  }
  return s;
}

// Warm up
sum(1e5); sum(1e5);
console.time("destructure array");
sum(1e8);
console.timeEnd("destructure array");

console.timeEnd: destructure array, 213.526000

console.timeEnd: destructure array, 1503.537000

Bug: v8:7728
Change-Id: Ib7aec1d5897989e6adb1af1eddd516d8b3866db5
Reviewed-on: https://chromium-review.googlesource.com/1047672Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53048}
      3fe7d698
  15. 07 May, 2018 1 commit
  17. 26 Apr, 2018 1 commit
  19. 26 Mar, 2018 1 commit
  21. 20 Feb, 2018 1 commit
  23. 23 Jan, 2018 1 commit
  25. 15 Jan, 2018 1 commit
    • Pierre Langlois's avatar
      [turbofan] Lower NumberConstant nodes to IntPtrConstant. · 7ac10da7
      Pierre Langlois authored 
      If a NumberConstant can be represented as a Smi, then lower it to a
IntPtrConstant node during simplified lowering. Thanks to this, all backends can
match Smi values that can also be encoded as immediates in the instruction
selector. Additionally, we can apply the same lowering to the CodeAssembler for
the snapshot.

As a result, we can remove `mov` instructions generated because Int32Matcher and
Int64Matcher didn't not recognize Smis:

For 32-bit target, it's common for Smis also be immediates: "if (a < 100) {}"
~~~
mov r1, #200 -> cmp r0, #200
cmp r0, r1   -> blt <>
blt <>       ->
~~~

On Arm64 particularly, we lose opportunites to use `cbz`: "if (a == 0) {}"
~~~
movz x0, #0x0 -> cbz x1 <>
cmp x1, x0    ->
b.eq <>       ->
~~~

Overall, we do not see an impact on benchmarks such as webtooling. However, we
do see noteworthy code size reduction, from 0.5% to 1.5%.

Bug: 
Change-Id: I7fbb718ad51b9036c3514fa31c1326bdd6f2b0e6
Reviewed-on: https://chromium-review.googlesource.com/848814Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#50569}
      7ac10da7
  27. 15 Dec, 2017 1 commit
    • Bill Budge's avatar
      [Memory] Create memory management API in v8::internal. · a449f09f
      Bill Budge authored 
      - Creates a memory management API in v8::internal, which corresponds
  to the existing one in base::OS.
- Implements the new API in terms of the old one.
- Changes all usage of the base::OS API to the one in v8::internal. This
  includes all tests, except platform and OS tests.
- Makes OS:: methods private.
- Moves all LSAN calls into the v8::internal functions.

Bug: chromium:756050
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Iaa3f022e3e12fdebf937f3c76b6c6455014beb8a
Reviewed-on: https://chromium-review.googlesource.com/794856
Commit-Queue: Bill Budge <bbudge@chromium.org>
Reviewed-by: 's avatarEric Holk <eholk@chromium.org>
Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50139}
      a449f09f
  29. 05 Dec, 2017 1 commit
  31. 28 Nov, 2017 1 commit
  33. 19 Oct, 2017 1 commit
  35. 13 Oct, 2017 1 commit
  37. 11 Oct, 2017 3 commits
    • Eric Holk (eholk)'s avatar
      Reland "Reland "[wasm] trap handlers: fall back on old signal handler"" · 1117da83
      Eric Holk (eholk) authored 
      This is a reland of cc237d87
Original change's description:
> Reland "[wasm] trap handlers: fall back on old signal handler"
> 
> This is a reland of ee4fe896
> Original change's description:
> > [wasm] trap handlers: fall back on old signal handler
> > 
> > This is primarily needed to test D8 under ASan. ASan installs a signal handler
> > early in the process startup to show stack traces from crashes. We need to make
> > sure that if V8 does not handle a signal then the existing handler gets a
> > chance.
> > 
> > This change only applies when using V8's default signal handler. When
> > integrating with the embedder's signal handler the behavior is unchanged.
> > 
> > Bug: chromium:771948
> > Change-Id: Ifd560acf9700ec5f714f009530258fa92c83cabe
> > Reviewed-on: https://chromium-review.googlesource.com/705823
> > Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> > Commit-Queue: Eric Holk <eholk@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#48429}
> 
> Bug: chromium:771948
> Change-Id: Ide307091c432fd933c48f89c51851b8dce44dd30
> Reviewed-on: https://chromium-review.googlesource.com/710114
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Commit-Queue: Eric Holk <eholk@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48435}

Bug: chromium:771948
Change-Id: I781dfe356a728760090b6ccfa58212096e8f20c8
Reviewed-on: https://chromium-review.googlesource.com/713956Reviewed-by: 's avatarDeepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48474}
      1117da83
    • Michael Achenbach's avatar
      Revert "Reland "[wasm] trap handlers: fall back on old signal handler"" · 33d4e209
      Michael Achenbach authored 
      This reverts commit cc237d87.

Reason for revert: breaks win clang:
https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20clang/builds/8538

Original change's description:
> Reland "[wasm] trap handlers: fall back on old signal handler"
> 
> This is a reland of ee4fe896
> Original change's description:
> > [wasm] trap handlers: fall back on old signal handler
> > 
> > This is primarily needed to test D8 under ASan. ASan installs a signal handler
> > early in the process startup to show stack traces from crashes. We need to make
> > sure that if V8 does not handle a signal then the existing handler gets a
> > chance.
> > 
> > This change only applies when using V8's default signal handler. When
> > integrating with the embedder's signal handler the behavior is unchanged.
> > 
> > Bug: chromium:771948
> > Change-Id: Ifd560acf9700ec5f714f009530258fa92c83cabe
> > Reviewed-on: https://chromium-review.googlesource.com/705823
> > Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> > Commit-Queue: Eric Holk <eholk@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#48429}
> 
> Bug: chromium:771948
> Change-Id: Ide307091c432fd933c48f89c51851b8dce44dd30
> Reviewed-on: https://chromium-review.googlesource.com/710114
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Commit-Queue: Eric Holk <eholk@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48435}

TBR=mseaborn@chromium.org,bradnelson@chromium.org,gdeepti@chromium.org,eholk@chromium.org,mark@chromium.org

Change-Id: If71f61ae186fc6be2006edeb2dffd7e2b6827d91
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:771948
Reviewed-on: https://chromium-review.googlesource.com/711854Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48436}
      33d4e209
    • Eric Holk's avatar
      Reland "[wasm] trap handlers: fall back on old signal handler" · cc237d87
      Eric Holk authored 
      This is a reland of ee4fe896
Original change's description:
> [wasm] trap handlers: fall back on old signal handler
> 
> This is primarily needed to test D8 under ASan. ASan installs a signal handler
> early in the process startup to show stack traces from crashes. We need to make
> sure that if V8 does not handle a signal then the existing handler gets a
> chance.
> 
> This change only applies when using V8's default signal handler. When
> integrating with the embedder's signal handler the behavior is unchanged.
> 
> Bug: chromium:771948
> Change-Id: Ifd560acf9700ec5f714f009530258fa92c83cabe
> Reviewed-on: https://chromium-review.googlesource.com/705823
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Commit-Queue: Eric Holk <eholk@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48429}

Bug: chromium:771948
Change-Id: Ide307091c432fd933c48f89c51851b8dce44dd30
Reviewed-on: https://chromium-review.googlesource.com/710114Reviewed-by: 's avatarDeepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48435}
      cc237d87
  39. 10 Oct, 2017 2 commits
    • Eric Holk's avatar
      Revert "[wasm] trap handlers: fall back on old signal handler" · 0a97c51f
      Eric Holk authored 
      This reverts commit ee4fe896.

Reason for revert: <INSERT REASONING HERE>

Original change's description:
> [wasm] trap handlers: fall back on old signal handler
> 
> This is primarily needed to test D8 under ASan. ASan installs a signal handler
> early in the process startup to show stack traces from crashes. We need to make
> sure that if V8 does not handle a signal then the existing handler gets a
> chance.
> 
> This change only applies when using V8's default signal handler. When
> integrating with the embedder's signal handler the behavior is unchanged.
> 
> Bug: chromium:771948
> Change-Id: Ifd560acf9700ec5f714f009530258fa92c83cabe
> Reviewed-on: https://chromium-review.googlesource.com/705823
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Commit-Queue: Eric Holk <eholk@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48429}

TBR=mseaborn@chromium.org,bradnelson@chromium.org,gdeepti@chromium.org,eholk@chromium.org,mark@chromium.org

Change-Id: Ib43b096831b15c312b3b460e59f268d5ea903f21
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:771948
Reviewed-on: https://chromium-review.googlesource.com/710034Reviewed-by: 's avatarEric Holk <eholk@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48430}
      0a97c51f
    • Eric Holk's avatar
      [wasm] trap handlers: fall back on old signal handler · ee4fe896
      Eric Holk authored 
      This is primarily needed to test D8 under ASan. ASan installs a signal handler
early in the process startup to show stack traces from crashes. We need to make
sure that if V8 does not handle a signal then the existing handler gets a
chance.

This change only applies when using V8's default signal handler. When
integrating with the embedder's signal handler the behavior is unchanged.

Bug: chromium:771948
Change-Id: Ifd560acf9700ec5f714f009530258fa92c83cabe
Reviewed-on: https://chromium-review.googlesource.com/705823Reviewed-by: 's avatarDeepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48429}
      ee4fe896
  41. 28 Sep, 2017 2 commits
    • Mostyn Bramley-Moore's avatar
      [jumbo] add unittests jumbo support · d6ead37d
      Mostyn Bramley-Moore authored 
      TBR=jkummerow@chromium.org

Bug: chromium:746958
Change-Id: I7500b6206c4ceb087672de5b61b7e7ad234bb425
Reviewed-on: https://chromium-review.googlesource.com/690397
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48213}
      d6ead37d
    • Peter Marshall's avatar
      [cleanup] Replace List with std::vector in api. · 329f6946
      Peter Marshall authored 
      The members of HandleScopeImplementer are copied with memcpy when
the isolate is transferred to another thread. List contained some
primitives which allowed us to manually free the backing store, which
was needed in order to ensure that threads would not hold on to
old pointers and use them later. With std::vector, we can't do that.

Here we change the HandleScopeImplementer to instead use a custom
structure DetachableVector, which contains a std::vector but allows
manual detaching and freeing of the backing store. This allows us to
maintain the old behavior.

Bug: v8:6333
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I6361d161cdb19878ba19ed51d6ba2fae99e8cdc0
Reviewed-on: https://chromium-review.googlesource.com/660125Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48197}
      329f6946
  43. 16 Sep, 2017 3 commits
    • Mircea Trofin's avatar
      Revert "Revert "[wasm] A simple allocator datastructure for off-the heap"" · 3d046986
      Mircea Trofin authored 
      This reverts commit ee5c31f3.

Reason for revert: Fixed compiler failure

Original change's description:
> Revert "[wasm] A simple allocator datastructure for off-the heap"
> 
> This reverts commit 110d9ab0.
> 
> Reason for revert: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20debug%20builder/builds/26607
> 
> Surprising we're seeing a failure on Linux 64 *after* CQ. Is the compiler there different?
> 
> Original change's description:
> > [wasm] A simple allocator datastructure for off-the heap
> > 
> > We'll use this allocator in a follow-up CL to:
> > - allocate speculative sizes of memory for a module that's being
> > compiled (e.g. 2*size of wasm code).
> > - each module will own such a sub-pool, and then use it to allocate
> > contiguous chunks of memory for code.
> > 
> > The underlying assumptions for the chosen allocation strategy is that:
> > - the allocation granularity for pools is 1 page, so that no one page
> > is owned by more than one wasm module
> > - typical pool sizes (given module sizes) are multiple pages.
> > - modules and module instances are typically few and long lived. Typically,
> > we expect one module and one instance. 
> > 
> > This means we shouldn't expect fragmentations that lead to code being
> > non-allocatable, or prohibitively many ranges.
> > 
> > The data structure just manages ranges of addresses. Virtual memory management
> > will be separate, as part of the responsibility of a "WasmHeap"
> > that will be introduced in the future. So will concurrency control.
> > 
> > Bug: 
> > Change-Id: Id99f46d10c25553b013054d994760f3c2a737c39
> > Reviewed-on: https://chromium-review.googlesource.com/669296
> > Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
> > Reviewed-by: Eric Holk <eholk@chromium.org>
> > Reviewed-by: Brad Nelson <bradnelson@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#48053}
> 
> TBR=bradnelson@chromium.org,mtrofin@chromium.org,eholk@chromium.org
> 
> Change-Id: Id82fa341b77624e4971f24c4757a9a666a65930c
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Reviewed-on: https://chromium-review.googlesource.com/670141
> Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
> Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48054}

TBR=bradnelson@chromium.org,mtrofin@chromium.org,eholk@chromium.org

Change-Id: Ib6a7a3e6098d2689e60cdca85ec77e57e5295e48
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/670142
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: 's avatarMircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48055}
      3d046986
    • Mircea Trofin's avatar
      Revert "[wasm] A simple allocator datastructure for off-the heap" · ee5c31f3
      Mircea Trofin authored 
      This reverts commit 110d9ab0.

Reason for revert: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20debug%20builder/builds/26607

Surprising we're seeing a failure on Linux 64 *after* CQ. Is the compiler there different?

Original change's description:
> [wasm] A simple allocator datastructure for off-the heap
> 
> We'll use this allocator in a follow-up CL to:
> - allocate speculative sizes of memory for a module that's being
> compiled (e.g. 2*size of wasm code).
> - each module will own such a sub-pool, and then use it to allocate
> contiguous chunks of memory for code.
> 
> The underlying assumptions for the chosen allocation strategy is that:
> - the allocation granularity for pools is 1 page, so that no one page
> is owned by more than one wasm module
> - typical pool sizes (given module sizes) are multiple pages.
> - modules and module instances are typically few and long lived. Typically,
> we expect one module and one instance. 
> 
> This means we shouldn't expect fragmentations that lead to code being
> non-allocatable, or prohibitively many ranges.
> 
> The data structure just manages ranges of addresses. Virtual memory management
> will be separate, as part of the responsibility of a "WasmHeap"
> that will be introduced in the future. So will concurrency control.
> 
> Bug: 
> Change-Id: Id99f46d10c25553b013054d994760f3c2a737c39
> Reviewed-on: https://chromium-review.googlesource.com/669296
> Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
> Reviewed-by: Eric Holk <eholk@chromium.org>
> Reviewed-by: Brad Nelson <bradnelson@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48053}

TBR=bradnelson@chromium.org,mtrofin@chromium.org,eholk@chromium.org

Change-Id: Id82fa341b77624e4971f24c4757a9a666a65930c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/670141Reviewed-by: 's avatarMircea Trofin <mtrofin@chromium.org>
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48054}
      ee5c31f3
    • Mircea Trofin's avatar
      [wasm] A simple allocator datastructure for off-the heap · 110d9ab0
      Mircea Trofin authored 
      We'll use this allocator in a follow-up CL to:
- allocate speculative sizes of memory for a module that's being
compiled (e.g. 2*size of wasm code).
- each module will own such a sub-pool, and then use it to allocate
contiguous chunks of memory for code.

The underlying assumptions for the chosen allocation strategy is that:
- the allocation granularity for pools is 1 page, so that no one page
is owned by more than one wasm module
- typical pool sizes (given module sizes) are multiple pages.
- modules and module instances are typically few and long lived. Typically,
we expect one module and one instance. 

This means we shouldn't expect fragmentations that lead to code being
non-allocatable, or prohibitively many ranges.

The data structure just manages ranges of addresses. Virtual memory management
will be separate, as part of the responsibility of a "WasmHeap"
that will be introduced in the future. So will concurrency control.

Bug: 
Change-Id: Id99f46d10c25553b013054d994760f3c2a737c39
Reviewed-on: https://chromium-review.googlesource.com/669296
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: 's avatarEric Holk <eholk@chromium.org>
Reviewed-by: 's avatarBrad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48053}
      110d9ab0
  45. 12 Sep, 2017 1 commit
  47. 30 Aug, 2017 2 commits
  49. 07 Aug, 2017 1 commit
    • Clemens Hammacher's avatar
      Move helper struct from logging.h to template-utils.h · 84dc3679
      Clemens Hammacher authored 
      I want to reuse the PassType helper in another CL, thus move it from
logging.h to template-utils.h, and rename it to pass_value_or_ref to
match other helpers there.
Also, add a boolean template parameter to declare whether array
dimensions should be removed. The default is to do so, which helps to
reduce the number of template instantiations by always passing arrays
as pointers.

Also, fix the usages in logging.h to actually use that helper when
instantiating other template functions. This will reduce the number of
instantiations.

And finally, we now have unit tests for the template utils, to document
what we expect, and test that this works on all architectures.

R=ishell@chromium.org, tebbi@chromium.org

Change-Id: I1ef5d2a489a5cfc7601c5ab13748674e3aa86cd6
Reviewed-on: https://chromium-review.googlesource.com/594247
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47191}
      84dc3679
  51. 31 Jul, 2017 1 commit
  53. 28 Jul, 2017 4 commits
  55. 27 Jul, 2017 1 commit