Skip to content

V
V8
Switch branch/tag
  1. 21 Aug, 2015 11 commits
    • binji's avatar
      Signal a blocked futex if the isolate is interrupted; don't busy-wait · b7cf7327
      binji authored 
      FutexEmulation::Wait can potentially block forever on a condition variable. We
want to allow this to be interrupted (for a debugger, or to terminate the
thread, for example).

The previous implementation would periodically wake up the waiter to check for
interrupts. This CL modifies the StackGuard so it wakes the blocked futex if
the thread should be interrupted.

BUG=chromium:497295
R=jarin@chromium.org
LOG=n

Review URL: https://codereview.chromium.org/1230303005

Cr-Commit-Position: refs/heads/master@{#30311}
      b7cf7327
    • mstarzinger's avatar
      Deprecate semi-correct CompilationInfo::flags predicate. · ef2fd24e
      mstarzinger authored 
      R=titzer@chromium.org

Review URL: https://codereview.chromium.org/1304053004

Cr-Commit-Position: refs/heads/master@{#30308}
      ef2fd24e
    • mlippautz's avatar
      [heap,cctest] Get rid of protected-for-sake-of-testing scope. · 477f5a81
      mlippautz authored 
      BUG=

Review URL: https://codereview.chromium.org/1293283003

Cr-Commit-Position: refs/heads/master@{#30301}
      477f5a81
    • hpayer's avatar
      Record slots in large objects. · 43f33038
      hpayer authored 
      BUG=

Review URL: https://codereview.chromium.org/1296713007

Cr-Commit-Position: refs/heads/master@{#30299}
      43f33038
    • wingo's avatar
      Parse arrow functions at proper precedence level · 9271b0cc
      wingo authored 
      BUG=v8:4211
LOG=Y
R=rossberg@chromium.org

Review URL: https://codereview.chromium.org/1286383005

Cr-Commit-Position: refs/heads/master@{#30298}
      9271b0cc
    • rossberg's avatar
      [es6] Parameter scopes for sloppy eval · 365fd7bc
      rossberg authored 
      This CL is a nightmare! For the utterly irrelevant edge case of a sloppy function with non-simple parameters and a call to direct eval, like here,

  let x = 1;
  function f(g = () => x) {
    var y
    eval("var x = 2")
    return g() + x  // f() = 3
  }

we have to do all of the following, on top of the declaration block ("varblock") contexts we already introduce around the body:

- Introduce the ability for varblock contexts to have both a ScopeInfo and an extension object (e.g., the body varblock in the example will contain both a static var y and a dynamic var x). No other scope needs that. Since there are no context slots left, a special new struct is introduced that pairs up scope info and extension object.

- When declaring lookup slots in the runtime, this new struct is allocated in the case where an extension object has to be added to a block scope (at which point the block's extension slot still contains a plain ScopeInfo).

- While at it, introduce some abstraction to access context extension slots in a more controlled manner, in order to keep special-casing to a minimum.

- Make sure that even empty varblock contexts do not get optimised away when they contain a sloppy eval, so that they can host the potential extension object.

- Extend dynamic search for declaration contexts (used by sloppy direct eval) to recognize varblock contexts.

- In the parser, if a function has a sloppy direct eval, introduce an additional varblock scope around each non-simple (desugared) parameter, as required by the spec to contain possible dynamic var bindings.

- In the pattern rewriter, add the ability to hoist the named variables the pattern declares to an outer scope. That is required because the actual destructuring has to be evaluated inside the protecting varblock scope, but the bindings that the desugaring introduces are in the outer scope.

- ScopeInfos need to save the information whether a block is a varblock, to make sloppy eval calls work correctly that deserialise them as part of the scope chain.

- Add the ability to materialize block scopes with extension objects in the debugger. Likewise, enable setting extension variables in block scopes via the debugger interface.

- While at it, refactor and unify some respective code in the debugger.

Sorry, this CL is large. I could try to split it up, but everything is rather entangled.

@mstarzinger: Please review the changes to contexts.
@yangguo: Please have a look at the debugger stuff.

R=littledan@chromium.org, mstarzinger@chromium.org, yangguo@chromium.org
BUG=v8:811,v8:2160
LOG=N

Review URL: https://codereview.chromium.org/1292753007

Cr-Commit-Position: refs/heads/master@{#30295}
      365fd7bc
    • rossberg's avatar
      [simd] Introduce SIMD types (as classes) · a60f1922
      rossberg authored 
      - Introduce a proper bit for SIMD primitive values.
- Introduce constructors for individual SIMD types. These are currently just classes, which seems good enough for now, given that we always have exactly one global map per SIMD type.

The only problem with using class types for SIMD is that a SIMD constant won't be a subtype of its specific type, only of the general SIMD type. But until we actually introduce SIMD constants into the compiler that shouldn't matter.

R=jarin@chromium.org
BUG=

Review URL: https://codereview.chromium.org/1303863002

Cr-Commit-Position: refs/heads/master@{#30294}
      a60f1922
    • mlippautz's avatar
      [heap] Thread through GC flags in memory reducer and incremental marking. · 7a21a70c
      mlippautz authored 
      BUG=chromium:520607
LOG=N

Review URL: https://codereview.chromium.org/1302273002

Cr-Commit-Position: refs/heads/master@{#30287}
      7a21a70c
    • wingo's avatar
      Fix parsing of arrow function formal parameters · bb43d6c0
      wingo authored 
      Not all parenthesized AssignmentExpressions whose components are valid
binding patterns are valid arrow function formal parameters.  In
particular (a,b,c)() is not valid, and in general the existing code
wasn't catching the tail productions of ConditionalExpression,
BinaryExpression, PostfixExpression, LeftHandSideExpression,
and MemberExpression.

Thanks to Adrian Perez for the test case.

BUG=v8:4211
LOG=Y
R=rossberg@chromium.org

Review URL: https://codereview.chromium.org/1306583002

Cr-Commit-Position: refs/heads/master@{#30286}
      bb43d6c0
    • yangguo's avatar
      Introduce SharedFunctionInfo::Iterator and Script::Iterator. · 4c5efa99
      yangguo authored 
      R=mvstanton@chromium.org

Review URL: https://codereview.chromium.org/1300333003

Cr-Commit-Position: refs/heads/master@{#30283}
      4c5efa99
    • mlippautz's avatar
      [heap] Cleanup and fix GC flags · a56f5373
      mlippautz authored 
      GC flags are now part of the {Heap} and should be respected by all
sub-components.

Also add a infrastructure to write tests accessing private methods.

Review URL: https://codereview.chromium.org/1301183002

Cr-Commit-Position: refs/heads/master@{#30281}
      a56f5373
  3. 20 Aug, 2015 6 commits
  5. 19 Aug, 2015 8 commits
  7. 18 Aug, 2015 11 commits
  9. 17 Aug, 2015 4 commits