Skip to content

V
V8
Switch branch/tag
  1. 22 Dec, 2014 2 commits
  3. 20 Dec, 2014 1 commit
    • alph's avatar
      Support multiple interrupt requests in v8 API. · 87e4bba3
      alph authored 
      There might be a number of clients that would like to
setup an interrupt request on the Isolate.

The patch also deprecates ClearInterrupt API. As long as
the interrupt handler is called outside of locks there's no way
to guarantee that the handler will not be called after
ClearInterrupt was invoked as it might have already started execution.

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

Cr-Commit-Position: refs/heads/master@{#25910}
      87e4bba3
  5. 18 Dec, 2014 1 commit
  7. 10 Dec, 2014 1 commit
  9. 05 Dec, 2014 1 commit
  11. 02 Dec, 2014 2 commits
    • yurys's avatar
      Add GetIdentityHash to v8::Name object API · f434123a
      yurys authored 
      v8::Object already has GetIdentityHash on it. This change adds its counterpart to v8::Name.

BUG=chromium:437416
LOG=Y

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

Cr-Commit-Position: refs/heads/master@{#25598}
      f434123a
    • thakis's avatar
      Set V8_CC_GNU or V8_CC_MSVC for clang in gcc / cl mode. · 643c24eb
      thakis authored 
      Also, remove V8_CC_CLANG since it's not read anywhere (and ideally shouldn't
be).

Clang tries to be compatible with gcc in clang mode, and with msvc in clang-cl
mode. It wants to go down the same code paths that these compilers want to go
down in most cases.

For example, V8PRIxPTR was set incorrectly on Windows 64-bit before this change
since macros.h assumed that checking for V8_CC_MSVC is enough to find LLP64
systems, but V8_CC_MSVC wasn't set for clang.  Most other existing checks for
V8_CC_MSVC should be taken for clang-cl too (and for the remaining ones,
clang-cl is happy with either code path).

Likewise, V8_IMMEDIATE_CRASH is currently set to a suboptimal value with clang
since __builtin_trap() is only used if V8_CC_GNU is set.

Including clang in the gcc and cl macros is also what chromium does.

BUG=chromium:82385
LOG=y

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

Cr-Commit-Position: refs/heads/master@{#25592}
      643c24eb
  13. 28 Nov, 2014 1 commit
  15. 27 Nov, 2014 1 commit
  17. 26 Nov, 2014 1 commit
  19. 24 Nov, 2014 1 commit
  21. 21 Nov, 2014 1 commit
  23. 19 Nov, 2014 1 commit
  25. 18 Nov, 2014 1 commit
  27. 17 Nov, 2014 1 commit
  29. 13 Nov, 2014 3 commits
  31. 12 Nov, 2014 3 commits
  33. 11 Nov, 2014 1 commit
  35. 07 Nov, 2014 1 commit
    • dslomov@chromium.org's avatar
      harmony_scoping: Implement lexical bindings at top level · 1a64b02d
      dslomov@chromium.org authored 
      This implements correct semantics for "extensible" top level lexical scope.
The entire lexical scope is represented at runtime by GlobalContextTable, reachable from native context and accumulating global contexts from every script loaded into the context.

When the new script starts executing, it does the following validation:
- checks the GlobalContextTable and global object (non-configurable own) properties against the set of declarations it introduces and reports potential conflicts.
- invalidates the conflicting PropertyCells on global object, so that any code depending on them will miss/deopt causing any contextual lookups to be reexecuted under the new bindings
- adds the lexical bindings it introduces to the GlobalContextTable

Loads and stores for contextual lookups are modified so that they check the GlobalContextTable before looking up properties on global object, thus implementing the shadowing of global object properties by lexical declarations.

R=adamk@chromium.org, rossberg@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#25220}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25220 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      1a64b02d
  37. 06 Nov, 2014 1 commit
    • svenpanne@chromium.org's avatar
      The idea behind of this solution is to use the existing "relocation info"... · d56a21eb
      svenpanne@chromium.org authored 
      The idea behind of this solution is to use the existing "relocation info" instead of consumption the CodeLinePosition events emitted by the V8 compilers.
During generation code and relocation info are generated simultaneously.
When code generation is done you each code object has associated "relocation info".
Relocation information lets V8 to mark interesting places in the generated code: the pointers that might need to be relocated (after garbage collection),
correspondences between the machine program counter and source locations for stack walking.

This patch:
1. Add more source positions info in reloc info to make it suitable for source level mapping.
The amount of data should not be increased dramatically because (1) V8 already marks interesting places in the generated code and
(2) V8 does not write redundant information (it writes a pair (pc_offset, pos) only if pos is changed and skips other).
I measured it on Octane benchmark - for unoptimized code the number of source positions may achieve 2x ('lin_solve' from NavierStokes benchmark).

2. When a sample happens, CPU profiler finds a code object by pc, then use its reloc info to match the sample to a source line.
If a source line is found that hit counter is increased by one for this line.

3. Add a new public V8 API to get the hit source lines by CDT CPU profiler.
Note that it's expected a minor patch in Blink to pack the source level info in JSON to be shown.

4.Add a test that checks how the samples are distributed through source lines.
It tests two cases: (1) relocation info created during code generation and (2) relocation info associated with precompiled function's version.

Patch from Denis Pravdin <denis.pravdin@intel.com>;

R=svenpanne@chromium.org, yurys@chromium.org

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

Patch from Weiliang <weiliang.lin@intel.com>.

Cr-Commit-Position: refs/heads/master@{#25182}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25182 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      d56a21eb
  39. 04 Nov, 2014 1 commit
  41. 03 Nov, 2014 1 commit
  43. 30 Oct, 2014 4 commits
  45. 29 Oct, 2014 1 commit
  47. 28 Oct, 2014 1 commit
  49. 27 Oct, 2014 3 commits
  51. 22 Oct, 2014 1 commit
  53. 21 Oct, 2014 3 commits