1. 28 Oct, 2010 1 commit
  2. 24 Sep, 2010 1 commit
  3. 26 Aug, 2010 1 commit
  4. 17 Aug, 2010 1 commit
  5. 16 Aug, 2010 1 commit
  6. 22 Jul, 2010 1 commit
  7. 21 Jul, 2010 1 commit
  8. 08 Jul, 2010 1 commit
  9. 30 Jun, 2010 1 commit
  10. 29 Jun, 2010 1 commit
  11. 24 Jun, 2010 1 commit
  12. 22 Jun, 2010 2 commits
  13. 17 Jun, 2010 1 commit
  14. 14 Jun, 2010 1 commit
  15. 08 Jun, 2010 1 commit
    • sgjesse@chromium.org's avatar
      More precise break points and stepping when debugging · 634fb915
      sgjesse@chromium.org authored
      Added support for more precise break points when debugging and stepping. To achieve that additional nop instructions are inserted where breaking would otherwise be impossible. The number of nop instructions inserted are sufficient to make place for patching with a call to a debug break code stub. On Intel that is 5 nop's for 32-bit and 13 for 64-bit. Om ARM 3 nop instructions (12 bytes) are required.
      
      In order to avoid inserting nop's in to many places a simple ast checker have been added to check whether there are breakable code in a statement or expression. If it is possible to break in an expression no additional break enabeling code is inserted.
      
      Added break locations to the true and false part of a conditional expression.
      
      Added stepping tests to cover more constructs.
      
      These changes are only in the full compiler.
      
      Changed the default value for the option --debugger in teh d8 shell from true to false. The reason for this is that with --debugger turned on the full compiler will be used for all code in when running d8, which can be unexpeceted.
      
      Review URL: http://codereview.chromium.org/2693002
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4820 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      634fb915
  16. 01 Jun, 2010 1 commit
  17. 27 May, 2010 1 commit
  18. 26 May, 2010 1 commit
  19. 20 May, 2010 1 commit
  20. 18 May, 2010 1 commit
  21. 17 May, 2010 2 commits
  22. 07 May, 2010 1 commit
  23. 27 Apr, 2010 1 commit
    • sgjesse@chromium.org's avatar
      Avoid constant pool blocking for too long · daf1ea39
      sgjesse@chromium.org authored
      The generation of the deferred code for named property load where the load was inlined did a constant pool blocking for the whole deferred code. Having large numbers of this type of deferred code generated one ofter the other effectively blocked the constant pool for all the deferred code causing 
      
      Removed the BeforeGenerate/AfterGenerate for the deferred code and made macro assembler StartBlockConstPool/EndBlockConstPool non-public. Re-introduced BlockConstPoolFor instead to use with BlockConstPoolScope to block some more instructions cross function calls.
      
      Also handle the use of native code counters for inlined named property load.
      Review URL: http://codereview.chromium.org/1787005
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4507 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      daf1ea39
  24. 23 Apr, 2010 1 commit
  25. 22 Apr, 2010 1 commit
  26. 21 Apr, 2010 3 commits
  27. 23 Mar, 2010 1 commit
  28. 19 Mar, 2010 1 commit
  29. 01 Mar, 2010 1 commit
  30. 05 Feb, 2010 1 commit
  31. 04 Feb, 2010 2 commits
  32. 02 Feb, 2010 1 commit
  33. 25 Jan, 2010 1 commit
  34. 09 Dec, 2009 1 commit
  35. 30 Nov, 2009 1 commit