1. 21 Feb, 2012 1 commit
  2. 20 Feb, 2012 1 commit
  3. 13 Feb, 2012 1 commit
  4. 26 Jan, 2012 1 commit
  5. 16 Jan, 2012 1 commit
  6. 13 Jan, 2012 1 commit
  7. 10 Jan, 2012 1 commit
  8. 05 Jan, 2012 1 commit
  9. 09 Dec, 2011 1 commit
  10. 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
  11. 21 Nov, 2011 1 commit
  12. 09 Nov, 2011 1 commit
  13. 03 Nov, 2011 1 commit
  14. 25 Oct, 2011 1 commit
  15. 21 Oct, 2011 1 commit
  16. 19 Oct, 2011 1 commit
  17. 17 Oct, 2011 1 commit
  18. 10 Oct, 2011 1 commit
  19. 06 Oct, 2011 1 commit
  20. 05 Oct, 2011 1 commit
  21. 23 Sep, 2011 1 commit
  22. 22 Sep, 2011 2 commits
  23. 21 Sep, 2011 1 commit
  24. 15 Sep, 2011 1 commit
  25. 13 Sep, 2011 1 commit
  26. 09 Sep, 2011 1 commit
  27. 11 Aug, 2011 1 commit
  28. 28 Jul, 2011 1 commit
  29. 18 Jul, 2011 1 commit
  30. 05 Jul, 2011 1 commit
    • ricow@chromium.org's avatar
      Introduce code flushing of RegExp code. · 0f682143
      ricow@chromium.org authored
      Due to issues relating mostly to chrome extensions we have lately been
      running into OOMs that are caused by our executable space running
      out. This change introduces flushing of code from regexps if we have
      not used the code for 5 mark sweeps.
      
      The approach is different from the normal function code flusing. Here
      we make a copy of the code inside the data array, and exchange the
      original code with a smi determined by the sweep_generation (a new
      heap variable increased everytime we do mark sweep/compact). If we
      encounter a smi in EnsureCompiled we simply reinstate the code
      object. If, in the marking phase of mark sweep, we find a regexp that
      already have a smi in the code field, and this is more than 5
      generations old we flush the code from the saved index.
      Review URL: http://codereview.chromium.org/7282026
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8532 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      0f682143
  31. 29 Jun, 2011 1 commit
  32. 27 Jun, 2011 1 commit
  33. 22 Jun, 2011 1 commit
  34. 16 Jun, 2011 1 commit
  35. 15 Jun, 2011 1 commit
  36. 14 Jun, 2011 1 commit
  37. 09 Jun, 2011 2 commits
  38. 24 May, 2011 1 commit
    • ricow@chromium.org's avatar
      Create stand-alone json parser (including scanner). · 3c7e1d70
      ricow@chromium.org authored
      The current json parser and scanner inherits fromt he normal scanners and parsers,
      which are more complicated than we need for parsing json.
      
      The supplied scanner works directly on the string supplied and has a
      fast case mode for scanning only ascii characters (it will simply
      create a substring or a symbol directly from the existing string). To
      allow for creating symbols from a substring I have added a
      SubStringAsciiSymbolKey that creates the hash based from our string
      without extracting the sub-string. In case we need to add the symbol
      it simply creates the symbol directly from the characters inside the
      given string.
      Review URL: http://codereview.chromium.org/7039037
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8029 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      3c7e1d70