1. 04 Sep, 2017 1 commit
    • jgruber's avatar
      [snapshot] Dynamically allocate builtin code objects in advance · b7b91142
      jgruber authored
      Our current deserializers (startup & partial) use a system of static memory
      reservations: required memory is determined at serialization time, which we
      then request before deserialization and dole out as-needed during
      deserialization.
      
      Lazy builtin deserialization needs a bit more flexibility. On the one hand, the
      amount of required memory varies since --lazy-deserialization can be switched
      on and off at runtime.
      
      On the other, builtin deserialization has been made order-independent, and we
      can encounter references to builtins before they have been deserialized.
      
      Both problems are solved by dynamically allocating required memory and
      initializing the builtins table with the (yet uninitialized) builtin Code
      objects.
      
      Bug: v8:6624
      Change-Id: Iee90992e91adb4ab45dae1acc81f64a108d12584
      Reviewed-on: https://chromium-review.googlesource.com/647748
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47789}
      b7b91142
  2. 18 Jul, 2017 1 commit
  3. 22 Jun, 2017 1 commit
  4. 12 May, 2017 1 commit
  5. 04 Oct, 2016 1 commit
  6. 07 Sep, 2016 2 commits
  7. 06 Sep, 2016 1 commit
  8. 30 Aug, 2016 1 commit
    • jacob.bramley's avatar
      [arm] Simplify run-time CPU selection. · 76ea8f2f
      jacob.bramley authored
      This replaces the target-selection options (such as "--enable-vfp3")
      with a simpler, absolute "--arm-arch" option. This eliminates inferences
      and avoids surprising behaviour in impossible situations (such as
      "--enable-vfp3 --no-enable-armv7").
      
      The available options are:
          --arm-arch=armv6          ARMv6 + VFPv2
          --arm-arch=armv7          ARMv7 + VFPv3-D32 + NEON
          --arm-arch=armv7+sudiv    ARMv7 + VFPv4-D32 + NEON + SUDIV
          --arm-arch=armv8          ARMv8 (+ all of the above)
      
      For now, the default setting is "armv8", which results in behaviour very
      similar to the existing defaults.
      
      BUG=v8:5077
      
      Review-Url: https://codereview.chromium.org/2223433002
      Cr-Commit-Position: refs/heads/master@{#39004}
      76ea8f2f
  9. 28 Aug, 2016 1 commit
  10. 25 Aug, 2016 1 commit
  11. 12 Aug, 2016 2 commits
  12. 10 Aug, 2016 2 commits
    • mlippautz's avatar
      Revert of [heap] Switch to 500k pages (patchset #24 id:780001 of... · 555c9619
      mlippautz authored
      Revert of [heap] Switch to 500k pages (patchset #24 id:780001 of https://codereview.chromium.org/2013713003/ )
      
      Reason for revert:
      Failures on waterfall:
      
      e.g. http://build.chromium.org/p/client.v8/builders/V8%20Linux64%20TSAN/builds/11134
      
      Original issue's description:
      > [heap] Switch to 500k pages
      >
      > - Decrease regular heap object size to 300k, keeping the same ration (60%)
      >   between this limit and page size.
      >
      > In a follow up, we can now get rid of the new space border page while
      > keeping the 1M minimum new space size.
      >
      > Some results (v8.infinite_scroll; 3 runs):
      > - evacuate.avg: +15.3% (1.4->1.2)
      > - evacuate.max: +24.4% (2.4->1.8)
      >
      > BUG=chromium:581412
      > LOG=N
      > R=hpayer@chromium.org, ulan@chromium.org, yangguo@chromium.org
      >
      > Committed: https://crrev.com/ffe5c670e1559d11e7b252e15fec38765e7dbe4f
      > Cr-Commit-Position: refs/heads/master@{#38533}
      
      TBR=hpayer@chromium.org,ulan@chromium.org,yangguo@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=chromium:581412
      
      Review-Url: https://codereview.chromium.org/2229403003
      Cr-Commit-Position: refs/heads/master@{#38537}
      555c9619
    • mlippautz's avatar
      [heap] Switch to 500k pages · ffe5c670
      mlippautz authored
      - Decrease regular heap object size to 300k, keeping the same ration (60%)
        between this limit and page size.
      
      In a follow up, we can now get rid of the new space border page while
      keeping the 1M minimum new space size.
      
      Some results (v8.infinite_scroll; 3 runs):
      - evacuate.avg: +15.3% (1.4->1.2)
      - evacuate.max: +24.4% (2.4->1.8)
      
      BUG=chromium:581412
      LOG=N
      R=hpayer@chromium.org, ulan@chromium.org, yangguo@chromium.org
      
      Review-Url: https://codereview.chromium.org/2013713003
      Cr-Commit-Position: refs/heads/master@{#38533}
      ffe5c670
  13. 27 Jul, 2016 1 commit
  14. 14 Jan, 2016 1 commit
    • joransiu's avatar
      S390: Makefile + Build Toolchain Updates · 1091c2f0
      joransiu authored
      This is the first of several commits to contribute Linux on z Systems
      (s390/s390x) port of V8.  We will be breaking up the changes into several
      (hopefully) logical commits.
      
      This commit contains the changes to V8 Makefile and build toolchains to
      introduce S390 macros and compiler options.  Just for awareness for reviewers
      is that s390 is 31-bit (not 32!) big-endian platform on Linux on z.  (MSB of address
      is used to distinguish between 24-bit vs 31-bit addressing!)  s390x is
      64-bit Linux on z.  Names follow the general linux convention on the platform.
      
      A quick roadmap on upcoming commits:
      - Add \#include of S390 header files in common files
      - S390 related tests + tooling changes
      - printf macro for printing size_t values.
      - S390 platform-specific code generation code (bulk of changes!)
      
      R=danno@chromium.org,svenpanne@chromium.org,michael_dawson@ca.ibm.com,jyan@ca.ibm.com,mtbrandyberry@ca.ibm.com
      BUG=
      
      Review URL: https://codereview.chromium.org/1585813002
      
      Cr-Commit-Position: refs/heads/master@{#33304}
      1091c2f0
  15. 30 Nov, 2015 1 commit
  16. 30 Oct, 2015 1 commit
  17. 29 Sep, 2015 1 commit
  18. 21 Jul, 2015 1 commit
  19. 16 Jan, 2015 1 commit
  20. 06 Oct, 2014 1 commit
  21. 15 Sep, 2014 1 commit
  22. 12 Sep, 2014 2 commits
  23. 11 Sep, 2014 1 commit
    • jochen@chromium.org's avatar
      Improve x32 detection macro. · 02213097
      jochen@chromium.org authored
      When targeting the Microsoft ABI in 64bit mode, clang defines __x86_64__ but
      doesn't define __LP64__ (Microsoft uses LLP64), so it would fall down the x32
      path. cl.exe doesn't define __x86_64__ in the first place, so it didn't have
      this problem.
      
      Rather than trying to guess pointer size by looking at __x86_64__ and __LP64__,
      check for pointer size directly using __POINTER_SIZE__. This is defined by both
      gcc and clang, and eliminiates this problem.
      
      This should fix hundreds of "error(clang): unknown type name 'Atomic64'" when
      compiling v8 on Windows with clang for 64 bit.
      
      BUG=chromium:82385
      LOG=n
      R=haitao.feng@intel.com, jochen@chromium.org
      
      Review URL: https://codereview.chromium.org/560903002
      
      Patch from Nico Weber <thakis@chromium.org>.
      
      git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@23855 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      02213097
  24. 01 Sep, 2014 1 commit
  25. 09 Jul, 2014 1 commit
  26. 30 Jun, 2014 1 commit
  27. 24 Jun, 2014 1 commit
  28. 10 Jun, 2014 1 commit
  29. 03 Jun, 2014 1 commit
  30. 28 May, 2014 1 commit