1. 03 Mar, 2011 2 commits
  2. 15 Feb, 2011 1 commit
  3. 13 Feb, 2011 1 commit
  4. 26 Jan, 2011 2 commits
  5. 12 Jan, 2011 1 commit
  6. 07 Dec, 2010 3 commits
  7. 26 Nov, 2010 1 commit
  8. 23 Sep, 2010 1 commit
    • kaznacheev@chromium.org's avatar
      Dynamically determine optimal instance size. · 06c86740
      kaznacheev@chromium.org authored
      The number of inobject properties used to be derived from the number
      of this property assignments in the constructor (and increased by 2 to
      allow for properties added later). This very often leads to wasted inobject 
      slots.
      
      This patch reclaims some of the unused inobject space by the following method:
       - for each constructor function the first several objects are allocated using the initial 
         ("generous) instance size estimation (this is called 'tracking phase').
       - during the tracking phase map transitions are tracked and actual property counts are collected.
       - at the end of the tracking phase instance sizes in the maps are decreased if necessary
         (starting with the function's initial map and traversing the transition tree).
       - all further allocation use more realistic instance size estimation.
      
      Shrinking generously allocated objects without costly heap traversal is made possible 
      by initializing their inobject properties with one_pointer_filler_map (instead of undefined). 
      
      The initial slack for the generous allocation is increased from 2 to 6 which really helps some tests.
      
      Review URL: http://codereview.chromium.org/3329019
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5510 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      06c86740
  9. 07 Sep, 2010 1 commit
  10. 26 Aug, 2010 1 commit
  11. 25 Aug, 2010 1 commit
  12. 20 Aug, 2010 1 commit
  13. 11 Aug, 2010 2 commits
  14. 14 Jun, 2010 1 commit
  15. 27 May, 2010 1 commit
  16. 26 May, 2010 1 commit
  17. 25 May, 2010 1 commit
    • vegorov@chromium.org's avatar
      Cardmarking writebarrier. · 675e711f
      vegorov@chromium.org authored
      - New сardmarking write barrier handles large objects and normal objects in a similar fashion (no more additional space for pointer tracking is required, no conditional branches in WB code).
      - Changes to enable oldspaces iteration without maps decoding:
      -- layout change for FixedArrays: length is stored as a smis (initial patch by
      Kevin Millikin)
      -- layout change for SharedFunctionInfo: integer fields are stored as smi on
      arm, ia32 and rearranged on x64.
      -- layout change for String: meaning of LSB bit is fliped (1 now means hash not
      computed); on x64 padding is added.
      -- layout of maps is _not_ changed. Map space is currently iterated in a special
      way.
      
      Review URL: http://codereview.chromium.org/2144006
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4715 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      675e711f
  18. 21 May, 2010 2 commits
  19. 20 May, 2010 3 commits
  20. 17 May, 2010 1 commit
    • mark@chromium.org's avatar
      Allow build-time selection between ia32 and x86_64 in the GYP/Xcode Mac · e9b5d785
      mark@chromium.org authored
      Chromium build.
      
      v8.gyp no longer sets any V8_TARGET_ARCH_* macro on the Mac. Instead, the
      proper V8_TARGET_ARCH_* macro will be set by src/globals.h in the same way as
      the V8_HOST_ARCH_* macro when it detects that no target macro is currently
      defined. The Mac build will attempt to compile all ia32 and x86_64 .cc files.
      #ifdef guards in each of these target-specific source files prevent their
      compilation when the associated target is not selected. For completeness,
      these #ifdef guards are also provided for the arm and mips .cc files.
      
      BUG=706
      TEST=x86_64 Mac GYP/Xcode-based Chromium build (still depends on other changes)
      Review URL: http://codereview.chromium.org/2133003
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4666 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      e9b5d785
  21. 07 May, 2010 1 commit
  22. 26 Apr, 2010 1 commit
  23. 24 Feb, 2010 1 commit
  24. 17 Feb, 2010 1 commit
  25. 15 Feb, 2010 1 commit
  26. 15 Jan, 2010 1 commit
  27. 12 Nov, 2009 1 commit
  28. 05 Nov, 2009 1 commit
    • sgjesse@chromium.org's avatar
      Fix issue 493: Infinite loop when debug break is set when entering function.apply. · 41d6cae4
      sgjesse@chromium.org authored
      In the generated code for function.apply there was a loop checking the stack limit for interruption. This loop would call into the runtime system to handle interuption and keep running until there was no interruption. However if the interuption was debug break the runtime system would never clear the interruption as debug break is prevented in builtins are prevented and the assumption here was that returning with the debug break flag set would move execution forward.
      
      Renamed initial_jslimit and initial_climit to real_jslimit and real_climit. Renamed a few external references related to the stack limit as well.
      
      Exposed the real stack limit to generated code to make the stack check when entering function.apply use the real stack limit and not the stack limit which is changed to signal interruption.
      
      Added the real stack limit to the roots array.
      
      BUG=http://code.google.com/p/v8/issues/detail?id=493
      TEST=cctest/test-debug/DebugBreakFunctionApply
      Review URL: http://codereview.chromium.org/345048
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3229 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      41d6cae4
  29. 28 Oct, 2009 1 commit
  30. 30 Sep, 2009 1 commit
  31. 28 Sep, 2009 1 commit
  32. 23 Sep, 2009 1 commit