Skip to content

V
V8
Switch branch/tag
  1. 14 Jun, 2010 1 commit
  3. 27 May, 2010 1 commit
  5. 26 May, 2010 1 commit
  7. 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
  9. 21 May, 2010 2 commits
  11. 20 May, 2010 3 commits
  13. 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
  15. 07 May, 2010 1 commit
  17. 26 Apr, 2010 1 commit
  19. 24 Feb, 2010 1 commit
  21. 17 Feb, 2010 1 commit
  23. 15 Feb, 2010 1 commit
  25. 15 Jan, 2010 1 commit
  27. 12 Nov, 2009 1 commit
  29. 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
  31. 28 Oct, 2009 1 commit
  33. 30 Sep, 2009 1 commit
  35. 28 Sep, 2009 1 commit
  37. 23 Sep, 2009 1 commit
  39. 16 Sep, 2009 1 commit
    • sgjesse@chromium.org's avatar
      Handle array construction on native code. · 677c043f
      sgjesse@chromium.org authored 
      The construction of arrays when using the the Array function either as a constructor or a normal function is now handled fully in generated code in most cases. Only when Array is called with one argument which is either negative or abowe JSObject::kInitialMaxFastElementArray (which is currently 1000) or if the allocated object cannot fit in the room left in new space is the runtime system entered.

Two new native code built-in functions are added one for normal invocation and one for the construct call. The existing C++ builtin is renamed, but kept. When the normal invocation cannot be handled in generated code the C++ builtin is called. When the construct invocation cannot be handled in native code the generic construct stub is called (which will end up in the C++ builtin through a construct trampoline).

One thing that might be changed is preserving esi (constructor function) during the handling of a construct call. We know precisily what function we where calling anyway and can just reload it. This could remove the parameter construct_call to ArrayNativeCode and remove the handling of this from that function.

The X64 and ARM implementations are not part of this changelist.
Review URL: http://codereview.chromium.org/193125

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2899 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      677c043f
  41. 07 Sep, 2009 1 commit
  43. 02 Sep, 2009 1 commit
  45. 01 Sep, 2009 2 commits
  47. 27 Aug, 2009 1 commit
  49. 24 Aug, 2009 1 commit
  51. 18 Aug, 2009 2 commits
  53. 17 Aug, 2009 1 commit
  55. 19 Jun, 2009 1 commit
  57. 10 Jun, 2009 1 commit
  59. 25 May, 2009 1 commit
  61. 20 May, 2009 1 commit
  63. 07 May, 2009 1 commit
  65. 27 Apr, 2009 1 commit
  67. 23 Apr, 2009 1 commit
  69. 21 Apr, 2009 1 commit