1. 24 Apr, 2019 1 commit
  2. 09 Apr, 2019 1 commit
  3. 03 Jan, 2019 1 commit
    • Clemens Hammacher's avatar
      [wasm] Force GC earlier to avoid running OOM · 9f90c8dc
      Clemens Hammacher authored
      We currently trigger a GC when creating a module while the remaining
      uncommitted code space is below 32MB. For bigger modules, this is not
      enough. Instead, make this limit relative: Trigger GC if we fall below
      50% of the available code space, and re-adjust this limit after each GC
      to avoid repeated GCs that do not free anything.
      
      R=ahaas@chromium.org
      
      Bug: v8:8624
      Change-Id: I7abfad3b57663d528a26d29232ad6bc2dc63cef4
      Reviewed-on: https://chromium-review.googlesource.com/c/1391753Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58527}
      9f90c8dc
  4. 18 May, 2018 1 commit
    • Georg Neis's avatar
      [flags] Print flags that were ignored. · 5330111d
      Georg Neis authored
      Command-line flags can be parsed in two modes. In the mode used by
      Chrome, an unrecognized flag causes the remaining arguments to be
      ignored. This is different from how d8 parses flags.
      
      Example:
      
      1) d8 --enable-slow-asserts --trace-ic
      2) content_shell --js-flags='--enable-slow-asserts --trace-ic'
      
      Assuming we compiled without ENABLE_SLOW_DCHECKS, in (1) we get a
      warning that --enable-slow-asserts is unknown. Nevertheless,
      --trace-ic will be enabled. In (2), we get an error that
      --enable-slow-asserts is unknown but --trace-ic will NOT be enabled
      (and neither does content_shell abort).
      
      This inconsistency is obviously very confusing. With this CL, we
      will at least print any flags that got ignored.
      
      Change-Id: I22bdb06d2b0accc234b3f5d596458809de364bce
      Reviewed-on: https://chromium-review.googlesource.com/1066010
      Commit-Queue: Georg Neis <neis@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53261}
      5330111d
  5. 30 Aug, 2017 1 commit
  6. 14 Mar, 2017 1 commit
  7. 30 Sep, 2015 1 commit
  8. 17 Mar, 2015 1 commit
  9. 13 Nov, 2014 1 commit
  10. 20 Jun, 2014 1 commit
  11. 05 Jun, 2014 1 commit
  12. 03 Jun, 2014 1 commit
  13. 28 May, 2014 1 commit
  14. 16 May, 2014 1 commit
    • yangguo@chromium.org's avatar
      Decouple CpuFeatures from serializer state. · fe243379
      yangguo@chromium.org authored
      Traditionally, we cross compile a snapshot iff the serializer is enabled.
      This will change in the future.
      
      Changes:
       - CpuFeatures probing is done once per process, depending on whether we
         cross compile.
       - CpuFeatures are consolidated into the platform-independent assembler.h
         as much as possible.
       - FLAG_enable_<feature> will only be checked at probing time (already the
         case for ARM).
       - The serializer state is cached by the MacroAssembler.
       - PlatformFeatureScope is no longer necessary.
       - CPUFeature enum values no longer map to CPUID bit fields.
      
      R=svenpanne@chromium.org
      
      Review URL: https://codereview.chromium.org/285233010
      
      git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21347 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      fe243379
  15. 29 Apr, 2014 1 commit
  16. 28 Apr, 2014 1 commit
  17. 10 Sep, 2013 1 commit
    • bmeurer@chromium.org's avatar
      Introduce a RandonNumberGenerator class. Refactor the random/private_random... · eb381b94
      bmeurer@chromium.org authored
      Introduce a RandonNumberGenerator class. Refactor the random/private_random uses in Isolate/Context.
      
      The RandomNumberGenerator is a pseudorandom number generator
      with 48-bit state. It is properly seeded using either
      
      (1) the --random-seed if specified, or
      (2) the entropy_source function if configured, or
      (3) /dev/urandom if available, or
      (4) falls back to Time and TimeTicks based seeding.
      
      Each Isolate now contains a RandomNumberGenerator, which replaces
      the previous private_random_seed.
      
      Every native context still has its own random_seed. But this random
      seed is now properly initialized during bootstrapping,
      instead of on-demand initialization. This will allow us to cleanup
      and speedup the HRandom implementation quite a lot (this is delayed
      for a followup CL)!
      
      Also stop messing with the system rand()/random(), which should
      not be done from a library anyway! We probably re-seeded the
      libc rand()/random() after the application (i.e. Chrome) already
      seeded it (with better entropy than what we used).
      
      Another followup CL will replace the use of the per-isolate
      random number generator for the address randomization and
      thereby get rid of the Isolate::UncheckedCurrent() usage in
      the platform code.
      
      TEST=cctest/test-random-number-generator,cctest/test-random
      R=mstarzinger@chromium.org
      
      Review URL: https://codereview.chromium.org/23548024
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16612 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      eb381b94
  18. 15 Dec, 2011 1 commit
  19. 30 Aug, 2010 1 commit
  20. 25 May, 2009 1 commit
  21. 11 Nov, 2008 1 commit
  22. 10 Nov, 2008 2 commits
  23. 17 Sep, 2008 1 commit
  24. 12 Sep, 2008 1 commit
  25. 09 Sep, 2008 1 commit
  26. 03 Jul, 2008 1 commit