1. 28 Sep, 2015 1 commit
  2. 14 Aug, 2015 1 commit
  3. 13 Aug, 2015 1 commit
  4. 01 Jun, 2015 1 commit
  5. 07 Apr, 2015 1 commit
  6. 23 Jan, 2015 1 commit
    • danno's avatar
      Remove the dependency of Zone on Isolate · c7b09aac
      danno authored
      Along the way:
      - Thread isolate parameter explicitly through code that used to
        rely on getting it from the zone.
      - Canonicalize the parameter position of isolate and zone for
        affected code
      - Change Hydrogen New<> instruction templates to automatically
        pass isolate
      
      R=mstarzinger@chromium.org
      LOG=N
      
      Review URL: https://codereview.chromium.org/868883002
      
      Cr-Commit-Position: refs/heads/master@{#26252}
      c7b09aac
  7. 10 Sep, 2014 1 commit
  8. 04 Aug, 2014 1 commit
  9. 30 Jun, 2014 1 commit
  10. 20 Jun, 2014 1 commit
  11. 17 Jun, 2014 1 commit
  12. 03 Jun, 2014 1 commit
  13. 09 May, 2014 1 commit
  14. 29 Apr, 2014 1 commit
  15. 24 Apr, 2014 1 commit
    • svenpanne@chromium.org's avatar
      CodeStubs contain their corresponding Isolate* now. (part 1) · dd30db90
      svenpanne@chromium.org authored
      This is a purely mechanical change, adding an Isolate* to the CodeStub
      constructor and a corresponding field plus a getter. A few methods in
      CodeStub and its subclasses can be simplified now, but this is done in
      a separate CL.
      
      The underlying reason apart from simplicity is that deep down in the
      call chain we need to detect if the serializer is active or not. This
      information will be part of the Isolate, not a global variable with
      funky synchronization primitives around it (which is fundamentally
      wrong and the underlying cause for race conditions and a catch-22
      during initialization).
      
      BUG=359977
      LOG=y
      R=mstarzinger@chromium.org
      
      Review URL: https://codereview.chromium.org/246643014
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20919 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      dd30db90
  16. 22 Apr, 2014 1 commit
  17. 07 Feb, 2014 2 commits
  18. 12 Sep, 2013 1 commit
  19. 11 Sep, 2013 1 commit
  20. 10 Sep, 2013 1 commit
  21. 03 Jul, 2013 1 commit
  22. 28 Jun, 2013 1 commit
  23. 07 Jun, 2013 1 commit
  24. 06 Jun, 2013 1 commit
  25. 04 Jun, 2013 1 commit
  26. 24 Apr, 2013 1 commit
  27. 13 Mar, 2013 1 commit
  28. 11 Mar, 2013 1 commit
  29. 09 Jan, 2013 2 commits
  30. 07 Jan, 2013 1 commit
  31. 04 Jan, 2013 1 commit
  32. 21 Nov, 2012 1 commit
  33. 15 Oct, 2012 1 commit
  34. 11 Jun, 2012 1 commit
  35. 06 Jun, 2012 1 commit
  36. 04 Jun, 2012 1 commit
  37. 22 May, 2012 1 commit
  38. 02 Apr, 2012 1 commit
    • erikcorry's avatar
      Regexp: Improve the speed that we scan for an initial point where a non-anchored · f14b93a5
      erikcorry authored
      regexp can match by using a Boyer-Moore-like table.  This is done by identifying
      non-greedy non-capturing loops in the nodes that eat any character one at a time.
      For example in the middle of the regexp /foo[\s\S]*?bar/ we find such a loop.
      There is also such a loop implicitly inserted at the start of any non-anchored
      regexp.
      
      When we have found such a loop we look ahead in the nodes to find the set of
      characters that can come at given distances.  For example for the regexp
      /.?foo/ we know that there are at least 3 characters ahead of us, and the sets
      of characters that can occur are [any, [f, o], [o]].  We find a range in the
      lookahead info where the set of characters is reasonably constrained.  In our
      example this is from index 1 to 2 (0 is not constrained).  We can now look 3
      characters ahead and if we don't find one of [f, o] (the union of [f, o] and
      [o]) then we can skip forwards by the range size (in this case 2).
      
      For Unicode input strings we do the same, but modulo 128.
      
      We also look at the first string fed to the regexp and use that to get a hint
      of the character frequencies in the inputs.  This affects the assessment of
      whether the set of characters is 'reasonably constrained'.
      
      We still have the old lookahead mechanism, which uses a wide load of multiple
      characters followed by a mask and compare to determine whether a match is
      possible at this point.
      Review URL: http://codereview.chromium.org/9965010
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11204 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      f14b93a5