Skip to content

V
V8
Switch branch/tag
  1. 31 Oct, 2014 1 commit
  3. 28 Oct, 2014 1 commit
  5. 19 Sep, 2014 1 commit
  7. 18 Sep, 2014 2 commits
  9. 04 Aug, 2014 1 commit
  11. 03 Jun, 2014 1 commit
  13. 29 Apr, 2014 1 commit
  15. 25 Apr, 2014 1 commit
  17. 11 Apr, 2014 1 commit
  19. 09 Apr, 2014 1 commit
  21. 08 Apr, 2014 1 commit
  23. 11 Mar, 2014 1 commit
  25. 23 Dec, 2013 1 commit
  27. 30 Jul, 2013 1 commit
  29. 05 Jul, 2013 1 commit
  31. 12 Mar, 2013 1 commit
  33. 25 Oct, 2012 1 commit
  35. 28 Aug, 2012 1 commit
  37. 24 Nov, 2011 1 commit
    • keuchel@chromium.org's avatar
      Introduce extended mode. · 1e9a7267
      keuchel@chromium.org authored 
      This CL introduces a third mode next to the non-strict
(henceforth called 'classic mode') and 'strict mode'
which is called 'extended mode' as in the current
ES.next specification drafts. The extended mode is based on
the 'strict mode' and adds new functionality to it. This
means that most of the semantics of these two modes
coincide.

The 'extended mode' is entered instead of the 'strict mode'
during parsing when using the 'strict mode' directive
"use strict" and when the the harmony-scoping flag is
active. This should be changed once it is fully specified how the 'extended mode' is entered.

This change introduces a new 3 valued enum LanguageMode
(see globals.h) corresponding to the modes which is mostly
used by the frontend code. This includes the following
components:
* (Pre)Parser
* Compiler
* SharedFunctionInfo, Scope and ScopeInfo
* runtime functions: StoreContextSlot,
  ResolvePossiblyDirectEval, InitializeVarGlobal,
  DeclareGlobals

The old enum StrictModeFlag is still used in the backend
when the distinction between the 'strict mode' and the 'extended mode' does not matter. This includes:
* SetProperty runtime function, Delete builtin
* StoreIC and KeyedStoreIC
* StubCache

Review URL: http://codereview.chromium.org/8417035

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10062 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      1e9a7267
  39. 14 Nov, 2011 1 commit
  41. 29 Jun, 2011 1 commit
    • vitalyr@chromium.org's avatar
      Suspend runtime profiler as soon as we exit JS. · 90c9f1b9
      vitalyr@chromium.org authored 
      Lots of web pages have really frequently firing timers that keep the
profiler thread spinning if we require a period of JS inactivity
before suspending the profiler. While it's possible to throttle it by
increasing the sleep delay and adjusting the duration of the required
inactive period, it seemed much simpler to just stop it immediately on
exiting JS.

Stopping the profiler this way effectively turned off two optimization
heuristics: 1) eager optimization (it's reset on waking up the
profiler and now the profiler wakes up much more frequently) and 2)
optimization throttling based on JS to non-JS state ratio (the ratio
is now 100%). I removed these two heuristics and found no performance
regressions so far.

R=ager@chromium.org
BUG=crbug.com/77625
TEST=none

Review URL: http://codereview.chromium.org/7274024

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8472 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      90c9f1b9
  43. 21 Mar, 2011 1 commit
  45. 18 Mar, 2011 3 commits
  47. 04 Feb, 2011 1 commit
  49. 07 Dec, 2010 3 commits
  51. 25 Oct, 2010 1 commit
  53. 23 Sep, 2010 1 commit
  55. 17 Aug, 2010 1 commit
  57. 07 Jun, 2010 1 commit
  59. 19 Apr, 2010 1 commit
  61. 23 Mar, 2010 2 commits
  63. 11 Mar, 2010 1 commit
  65. 04 Mar, 2010 1 commit
  67. 02 Mar, 2010 1 commit