Skip to content

V
V8
Switch branch/tag
  1. 07 Nov, 2017 1 commit
  3. 20 Oct, 2017 2 commits
  5. 13 Oct, 2017 1 commit
  7. 04 Oct, 2017 1 commit
  9. 28 Sep, 2017 1 commit
  11. 28 Aug, 2017 1 commit
  13. 23 Aug, 2017 1 commit
  15. 31 Jul, 2017 1 commit
  17. 30 Jun, 2017 1 commit
    • Jaime Bernardo's avatar
      [build] Set MSVS .obj folders in gyp for v8_base · 3bef2af6
      Jaime Bernardo authored 
      Building on Windows with gyp fails depending on the result from
sharding the src/v8.gyp:v8_base target. If two source files with the
same name are in the same shard, their output object file path would
conflict with one another. One example of this conflict is v8_base's
runtime/runtime.cc and the V8 inspector's protocol/Runtime.cpp that
is generated at build time, for which the files runtime.obj and
Runtime.obj would be created, but MSVS overwrites one of them with
the other.

Dividing the .obj output path by the original source's extension
prevents this overwrite.

Refs: https://github.com/nodejs/node/pull/13959
Bug: 
Change-Id: I158e6178f2511297899ee50ea159f574916f903f
Reviewed-on: https://chromium-review.googlesource.com/556599Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46354}
      3bef2af6
  19. 21 Jun, 2017 1 commit
  21. 09 Jun, 2017 1 commit
  23. 27 Feb, 2017 1 commit
  25. 11 Feb, 2017 1 commit
  27. 27 Dec, 2016 1 commit
  29. 08 Dec, 2016 1 commit
  31. 27 Oct, 2016 1 commit
  33. 26 Oct, 2016 1 commit
  35. 17 Oct, 2016 1 commit
  37. 01 Sep, 2016 1 commit
  39. 31 Aug, 2016 2 commits
  41. 16 Aug, 2016 1 commit
  43. 14 Jul, 2016 1 commit
  45. 11 Jul, 2016 1 commit
  47. 03 Jul, 2016 1 commit
    • honggyu.kp's avatar
      gdb-v8-support.py: Fix old style print statement · c52685a5
      honggyu.kp authored 
      Since python3 does not use the old print statement, it may not be able
to load gdb-v8-support.py script in gdb as below:

  (gdb) source tools/gdb-v8-support.py
    File "tools/gdb-v8-support.py", line 170
      print result
                 ^
  SyntaxError: Missing parentheses in call to 'print'

This fixes print statement for both python2 and python3.

R=jochen@chromium.org
BUG=

Review-Url: https://codereview.chromium.org/2084163004
Cr-Commit-Position: refs/heads/master@{#37488}
      c52685a5
  49. 14 Jun, 2016 1 commit
    • oleksandr.chekhovskyi's avatar
      Parser: Report use counts once per feature · 2f6be682
      oleksandr.chekhovskyi authored 
      Reporting use counts by invoking a callback once per occurrence has
a large overhead cost in certain situations, for example when it needs
to be dispatched to a different thread (which is the case for Web Workers).

Parsing large scripts can produce a lot of occurrences (strict/sloppy mode
once per function).

Chromium (the only known user of UseCounters so far) does not actually care
about number of occurrences, but simply whether they happened at least once.
This commit changes behavior to report features at most once, which dramatically
improves performance for impacted use cases, and should not affect the only
known real world usage.

R=littledan@chromium.org
BUG=chromium:614775

Review-Url: https://codereview.chromium.org/2062203002
Cr-Commit-Position: refs/heads/master@{#36979}
      2f6be682
  51. 23 May, 2016 1 commit
    • nexus226's avatar
      tools: Fix a syntax error in plot-timer-events · 726d3be8
      nexus226 authored 
      This fixes a syntax error in plot-timer-events script.

Before:
  $ out/x64.release/d8 --prof --log-timer-events script.js
  $ tools/plot-timer-events v8.log
  tools/plot-timer-events: 75: tools/plot-timer-events: options+=1343: not found
  --distortion=
  Cmdline args: [options] [log-file-name]
  Default log file name is "v8.log".
    ...

After:
  $ out/x64.release/d8 --prof --log-timer-events script.js
  $ tools/plot-timer-events v8.log
  $ ls timer-events.png
  timer-events.png

BUG=

Review-Url: https://codereview.chromium.org/1961873002
Cr-Commit-Position: refs/heads/master@{#36434}
      726d3be8
  53. 15 Apr, 2016 1 commit
  55. 31 Mar, 2016 1 commit
  57. 11 Mar, 2016 1 commit
  59. 20 Feb, 2016 1 commit
  61. 29 Jan, 2016 1 commit
    • xaxxon's avatar
      Make handle ctors explicit · b6c9b703
      xaxxon authored 
      Without this change, the v8::Local<> constructor will be picked up by the
compiler as an option for an implicit cast for any pointer type.  This leads
to bad error messages when accidentally passing an erroneous pointer type to
a function wanting a Local<> (complains about a pointer assignment in Local<>'s
constructor as opposed to a bad type for the parameter of the function being
called) and also causes ambiguity errors where none should exist when calling
overloaded functions (for example a function taking either a std::string or a
v8::Local<v8::Script> cannot be called with a const char * because the compiler
sees both types as being constructable with a const char *).

R=jochen@chromium.org
BUG=

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

Cr-Commit-Position: refs/heads/master@{#33602}
      b6c9b703
  63. 28 Jan, 2016 1 commit
  65. 16 Dec, 2015 1 commit
    • akodat's avatar
      Add Isolate::DiscardThreadSpecificMetadata method to embedder API. · aeb8073c
      akodat authored 
      If many threads use the same Isolate (or many Isolates) and then
terminate, their PerIsolateThreadData objects are never cleaned
up, resulting in a slow memory leak and, worse, the
PerIsolateThreadData chain getting larger and larger, adversely
affecting performance.

In this situation, embedders will now be encouraged to apply
DiscardThreadSpecificMetadata against any Isolate a thread is
done with, especially if the thread is about to terminate.

Note that it is harmless to run DiscardThreadSpecificMetadata
against an Isolate for which a thread has no thread data and
per-Isolate thread data can be reestablished if a thread starts
using an Isolate again after running DiscardThreadSpecificMetadata
against it.

It is, however, an embedder error to run
DiscardThreadSpecificMetadata against an Isolate in thread with a
Locker for the Isolate in the stack or against an Entered Isolate.

This change cannot cause any change in behavior in existing apps
as the only added coded can only be reached via the new
DiscardThreadSpecificMetadata method.

R=Jakob, jochen
BUG=

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

Cr-Commit-Position: refs/heads/master@{#32909}
      aeb8073c
  67. 15 Dec, 2015 1 commit
  69. 12 Nov, 2015 1 commit
  71. 30 Oct, 2015 1 commit
  73. 14 Oct, 2015 1 commit
  75. 24 Sep, 2015 1 commit