1. 17 Mar, 2011 3 commits
  2. 14 Mar, 2011 1 commit
  3. 09 Mar, 2011 1 commit
  4. 15 Feb, 2011 1 commit
  5. 04 Feb, 2011 1 commit
  6. 28 Jan, 2011 1 commit
  7. 25 Jan, 2011 2 commits
  8. 21 Jan, 2011 1 commit
  9. 07 Jan, 2011 1 commit
    • sgjesse@chromium.org's avatar
      Fix GC issue in instanceof stub · 426f13e0
      sgjesse@chromium.org authored
      The the call of the builtin in InstanceofStub was not correctly protected with an internal frame leading to the return address being handled as a pointer during GC.
      
      Marked the Instanceof stub as allowing stub calls (the RecordWriteStub was removed some days ago).
      
      This issue was not caught by the assertion designed for this when debug mode is run with --debug-code (which out tests always does) as generating code for Abort set the allow stub calls flag to true. This has been fixed by restoring the allow stub calls flag correctly.
      Review URL: http://codereview.chromium.org/6097010
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6218 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      426f13e0
  10. 06 Jan, 2011 1 commit
  11. 05 Jan, 2011 1 commit
    • sgjesse@chromium.org's avatar
      Optimize instanceof further · 7311e10f
      sgjesse@chromium.org authored
      If the instance of is performed against what is beliwed to be a constant global function inline the instance of check and have the call to the instanceof stub in deferred code. The inlined check will be patched by the instanceof stub when called from deferred code. This is indicated by the lithium instruction LInstanceOfKnownGlobal.
      
      To help the patching the delta from the return address to the patch site is placed just below the return address in the edi slot of the pushad/popad ares. This is safe because the edi register (which is pushed last) is a temporary for the lithium instruction.
      
      As the instanceof stub can call other JavaScript an additional marking for saving all double registers have been added.
      
      Also tweaked the instanceof stub to produce true/false objects instead of 0/1 for the case with deferred code.
      Review URL: http://codereview.chromium.org/5990005
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6173 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      7311e10f
  12. 21 Dec, 2010 1 commit
  13. 16 Dec, 2010 1 commit
  14. 15 Dec, 2010 1 commit
  15. 14 Dec, 2010 1 commit
  16. 13 Dec, 2010 2 commits
  17. 07 Dec, 2010 3 commits
  18. 15 Nov, 2010 1 commit
  19. 09 Nov, 2010 1 commit
  20. 25 Oct, 2010 1 commit
  21. 21 Oct, 2010 1 commit
  22. 15 Sep, 2010 1 commit
  23. 02 Sep, 2010 1 commit
  24. 30 Aug, 2010 1 commit
  25. 28 Jun, 2010 1 commit
  26. 01 Mar, 2010 1 commit
  27. 23 Feb, 2010 1 commit
  28. 16 Feb, 2010 1 commit
  29. 05 Feb, 2010 1 commit
  30. 29 Jan, 2010 1 commit
  31. 08 Jan, 2010 1 commit
  32. 07 Jan, 2010 1 commit
  33. 06 Jan, 2010 1 commit
    • sgjesse@chromium.org's avatar
      Direct call to native RegExp code from JavaScript. · 429f3cf9
      sgjesse@chromium.org authored
      Calls to RegExp no longer have to be via a call to the runtime system. A new stub have been added which can handle this call in generated code. The stub checks all the parameters and creates RegExp entry frame in the same way as it is created by the runtime system. Bailout to the runtime system is done whenever an uncommon situation is encountered or when the static data used is not initialized. After running the native RegExp code the last match info is updated like in the runtime system.
      
      Currently only ASCII strings are handled.
      
      Added another argument to the RegExp entry frame. It indicated whether the call is direct from JavaScript code or through the runtime system. This information is used when RegExp execution is interrupted. If an interruption happens when RegExp code is called directly a retry is issued causing the interruption to be handled via the runtime system. The reason for this is that the direct call to RegExp code does not support garbage collection.
      Review URL: http://codereview.chromium.org/521028
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3542 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      429f3cf9
  34. 22 Dec, 2009 1 commit