Skip to content

V
V8
Switch branch/tag
  1. 11 Nov, 2016 6 commits
  3. 10 Nov, 2016 5 commits
  5. 09 Nov, 2016 5 commits
  7. 08 Nov, 2016 3 commits
  9. 07 Nov, 2016 4 commits
    • machenbach's avatar
      Revert of [wasm] Indirect calls without function table cause validation... · 32ec567d
      machenbach authored 
      Revert of [wasm] Indirect calls without function table cause validation errors. (patchset #3 id:40001 of https://codereview.chromium.org/2484623002/ )

Reason for revert:
Speculative revert for blocking roll:
https://codereview.chromium.org/2479233002/

Original issue's description:
> [wasm] Indirect calls without function table cause validation errors.
>
> The spec defines that indirect calls in WebAssembly code should cause a
> validation error if no function table exists.
>
> The CL contains the following changes:
> 1) Throw a validation error for indirect calls if the function table
>    not exist.
> 2) Do not create TF nodes to throw a runtime error for indirect calls
>    if the function table does not exist.
> 3) Fix existing unit tests by creating a dummy function table.
> 4) Add new a new test which tests that indirect calls without function
>    table cause a validation error.
>
> R=rossberg@chromium.org
> CC=titzer@chromium.org
>
> TEST=unittests/AstDecoderTest.IndirectCallsWithoutTableCrash

TBR=rossberg@chromium.org,titzer@chromium.org,ahaas@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

Review-Url: https://codereview.chromium.org/2479283002
Cr-Commit-Position: refs/heads/master@{#40811}
      32ec567d
    • neis's avatar
      [compiler] Generalize context load/store operations in code-stub-assembler. · 08da5c98
      neis authored 
      The existing Load/StoreContextElement operations take the index as an int.  This
CL adds versions that take the index as a Node.  These already existed in the
interpreter-assembler, from which they are now removed.

R=mstarzinger@chromium.org, rmcilroy@chromium.org
BUG=

Review-Url: https://codereview.chromium.org/2473003004
Cr-Commit-Position: refs/heads/master@{#40810}
      08da5c98
    • ahaas's avatar
      [wasm] Indirect calls without function table cause validation errors. · 3de52047
      ahaas authored 
      The spec defines that indirect calls in WebAssembly code should cause a
validation error if no function table exists.

The CL contains the following changes:
1) Throw a validation error for indirect calls if the function table
   not exist.
2) Do not create TF nodes to throw a runtime error for indirect calls
   if the function table does not exist.
3) Fix existing unit tests by creating a dummy function table.
4) Add new a new test which tests that indirect calls without function
   table cause a validation error.

R=rossberg@chromium.org
CC=titzer@chromium.org

TEST=unittests/AstDecoderTest.IndirectCallsWithoutTableCrash

Review-Url: https://codereview.chromium.org/2484623002
Cr-Commit-Position: refs/heads/master@{#40802}
      3de52047
    • ahaas's avatar
      [wasm] Compare the maximum memory size with the spec limit, not with the V8 limit · 15d4984b
      ahaas authored 
      The maximum memory size is a user-defined upper limit for the size of
the memory of a WebAssembly instance. The actual limit is the minimum of
the user-defined limit and the V8 limit. With this CL we allow the
user-defined limit to be greater than the V8 limit, which is required by
the spec.

R=titzer@chromium.org
CC=gdeepti@chromium.org

TEST=unittests/WasmModuleVerifyTest.MaxMaximumMemorySize

Review-Url: https://codereview.chromium.org/2484643002
Cr-Commit-Position: refs/heads/master@{#40801}
      15d4984b
  11. 04 Nov, 2016 3 commits
  13. 03 Nov, 2016 3 commits
  15. 02 Nov, 2016 3 commits
    • danno's avatar
      [turbofan] Support variable size argument removal in TF-generated functions · fe552636
      danno authored 
      This is preparation for using TF to create builtins that handle variable number of
arguments and have to remove these arguments dynamically from the stack upon
return.

The gist of the changes:
- Added a second argument to the Return node which specifies the number of stack
  slots to pop upon return in addition to those specified by the Linkage of the
  compiled function.
- Removed Tail -> Non-Tail fallback in the instruction selector. Since TF now should
  handles all tail-call cases except where the return value type differs, this fallback
  was not really useful and in fact caused unexpected behavior with variable
  sized argument popping, since it wasn't possible to materialize a Return node
  with the right pop count from the TailCall without additional context.
- Modified existing Return generation to pass a constant zero as the additional
  pop argument since the variable pop functionality

LOG=N

Review-Url: https://codereview.chromium.org/2446543002
Cr-Commit-Position: refs/heads/master@{#40699}
      fe552636
    • bmeurer's avatar
      [turbofan] Assign proper types to Parameter nodes. · 3f3bacc3
      bmeurer authored 
      R=epertoso@chromium.org

Review-Url: https://codereview.chromium.org/2223873002
Cr-Commit-Position: refs/heads/master@{#40695}
      3f3bacc3
    • machenbach's avatar
      Revert of [turbofan] Support variable size argument popping in TF-generated... · c61902e0
      machenbach authored 
      Revert of [turbofan] Support variable size argument popping in TF-generated functions (patchset #13 id:240001 of https://codereview.chromium.org/2446543002/ )

Reason for revert:
Seems to break arm64 sim debug and blocks roll:
https://build.chromium.org/p/client.v8.ports/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20debug/builds/3294

Original issue's description:
> [turbofan] Support variable size argument removal in TF-generated functions
>
> This is preparation for using TF to create builtins that handle variable number of
> arguments and have to remove these arguments dynamically from the stack upon
> return.
>
> The gist of the changes:
> - Added a second argument to the Return node which specifies the number of stack
>   slots to pop upon return in addition to those specified by the Linkage of the
>   compiled function.
> - Removed Tail -> Non-Tail fallback in the instruction selector. Since TF now should
>   handles all tail-call cases except where the return value type differs, this fallback
>   was not really useful and in fact caused unexpected behavior with variable
>   sized argument popping, since it wasn't possible to materialize a Return node
>   with the right pop count from the TailCall without additional context.
> - Modified existing Return generation to pass a constant zero as the additional
>   pop argument since the variable pop functionality
>
> LOG=N

TBR=bmeurer@chromium.org,mstarzinger@chromium.org,epertoso@chromium.org,danno@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
NOPRESUBMIT=true

Review-Url: https://codereview.chromium.org/2473643002
Cr-Commit-Position: refs/heads/master@{#40691}
      c61902e0
  17. 31 Oct, 2016 2 commits
    • danno's avatar
      [turbofan] Support variable size argument removal in TF-generated functions · 5319b50c
      danno authored 
      This is preparation for using TF to create builtins that handle variable number of
arguments and have to remove these arguments dynamically from the stack upon
return.

The gist of the changes:
- Added a second argument to the Return node which specifies the number of stack
  slots to pop upon return in addition to those specified by the Linkage of the
  compiled function.
- Removed Tail -> Non-Tail fallback in the instruction selector. Since TF now should
  handles all tail-call cases except where the return value type differs, this fallback
  was not really useful and in fact caused unexpected behavior with variable
  sized argument popping, since it wasn't possible to materialize a Return node
  with the right pop count from the TailCall without additional context.
- Modified existing Return generation to pass a constant zero as the additional
  pop argument since the variable pop functionality

LOG=N

Review-Url: https://codereview.chromium.org/2446543002
Cr-Commit-Position: refs/heads/master@{#40678}
      5319b50c
    • jbroman's avatar
      Remove DCHECK that transferred array buffers are neutered or shared. · fa33489f
      jbroman authored 
      While this seems like it should be true, the array buffer is not actually
neutered until the end of cloning. This is so that, if an exception is thrown
during serialization, the original array buffer is not left neutered. As a
result, Blink will not have neutered the buffer.

This fixes some DCHECK failures during layout tests.

BUG=chromium:148757

Review-Url: https://codereview.chromium.org/2466563002
Cr-Commit-Position: refs/heads/master@{#40675}
      fa33489f
  19. 29 Oct, 2016 1 commit
  21. 28 Oct, 2016 3 commits
  23. 27 Oct, 2016 1 commit
    • leszeks's avatar
      [ignition] Add a property call bytecode · c4d770b1
      leszeks authored 
      This is a new bytecode which behaves (for now) exactly like Call,
except that in turbofan graph building we can set the
ConvertReceiverMode to NotNullOrUndefined.

I observe a 1% improvement on Box2D, I'd expect a similar improvement on
other OOP heavy code.

Review-Url: https://codereview.chromium.org/2450243002
Cr-Commit-Position: refs/heads/master@{#40610}
      c4d770b1
  25. 26 Oct, 2016 1 commit
    • heimbuef's avatar
      New zone-backed list datastructure to replace ZoneList · 610c0d75
      heimbuef authored 
      Since ZoneLists are essentially non-standard ZoneVectors and have a bad
growing behaviour (ZoneList-allocations make up ~50% of website parse
zone memory) we should stop using them. The zone-containers are merely
a clean-up, with none of them actually better suited to be used with
zones. This new datastructure allows most operations of a LinkedList (
except pop_first and insertAt/removeAt) but uses about the same memory
as a well-initialized ZoneVector/ZoneList (<3% overhead with reasonably
large lists). It also never attempts to free memory again (which would
not work in zones anyway).

The ZoneChunkList is essentially a doubly-linked-list of arrays of
variable size.

Some test-results where I tried storing 16k pointers in different list
types (lists themselves also zone-allocated):

List type                       Zone memory used   Time taken
-----------------------------------------------------------------------
Zone array (for comparison)     131072 B

Ideally initialized ZoneList    131088 B           0.062ms

ChunkZoneList                   134744 B           0.052ms <--new thing

ZoneDeque                       141744 B

ZoneLinkedList                  393264 B

Initially empty ZoneList        524168 B           0.171ms <--right now

ChunkZoneList only push_front   524320 B

Review-Url: https://codereview.chromium.org/2449383002
Cr-Commit-Position: refs/heads/master@{#40602}
      610c0d75