1. 18 Jun, 2015 1 commit
  2. 15 Jun, 2015 1 commit
  3. 10 Jun, 2015 1 commit
  4. 09 Jun, 2015 2 commits
  5. 08 Jun, 2015 1 commit
    • jarin's avatar
      Unify decoding of deoptimization translations. · 9127d4ee
      jarin authored
      This unifies methods Deoptimizer::DoTranslateCommand, Deotpimizer::DoTranslateObject and the arguments object materializer.
      
      To unify these, we have to separate reading of the input frame from writing to the output frame because the argument materializer does not write to output frames.
      
      Instead, we now deoptimize in following stages:
      
      1. Read out the input frame/registers, decode them using the translations from the deoptimizer and store them in the deoptimizer (Deoptimizer::translated_state_). This is done in TranslatedState::Init.
      
      2. Write out into the output frame buffer all the values that do not require allocation. We also remember references to the values that require materialization. As before, this is done in Deoptimizer::DoCompute*Frame method, but instead calling to DoTranslateCommand, we use the translated frame to obtain the values and write them to the output frames.
      
      3. The platform specific code then sets up the output frames and calls into the deoptimization notification. This has not been changed at all.
      
      4. Once the stack is setup, we handlify all the references in the saved translated values (TranslatedState::Prepare).
      
      5. Finally, we materialize all the values we remembered in step (1) and write them to their frames on the stack (using the TranslatedValue::GetValue method).
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1136223004
      
      Cr-Commit-Position: refs/heads/master@{#28826}
      9127d4ee
  6. 04 Jun, 2015 1 commit
    • mbrandy's avatar
      Add support for Embedded Constant Pools for PPC and Arm · eac7f046
      mbrandy authored
      Embed constant pools within their corresponding Code
      objects.
      
      This removes support for out-of-line constant pools in favor
      of the new approach -- the main advantage being that it
      eliminates the need to allocate and manage separate constant
      pool array objects.
      
      Currently supported on PPC and ARM.  Enabled by default on
      PPC only.
      
      This yields a 6% improvment in Octane on PPC64.
      
      R=bmeurer@chromium.org, rmcilroy@chromium.org, michael_dawson@ca.ibm.com
      BUG=chromium:478811
      LOG=Y
      
      Review URL: https://codereview.chromium.org/1162993006
      
      Cr-Commit-Position: refs/heads/master@{#28801}
      eac7f046
  7. 03 Jun, 2015 1 commit
  8. 02 Jun, 2015 1 commit
    • mbrandy's avatar
      Add support for Embedded Constant Pools for PPC and Arm · a9404029
      mbrandy authored
      Embed constant pools within their corresponding Code
      objects.
      
      This removes support for out-of-line constant pools in favor
      of the new approach -- the main advantage being that it
      eliminates the need to allocate and manage separate constant
      pool array objects.
      
      Currently supported on PPC and ARM.  Enabled by default on
      PPC only.
      
      This yields a 6% improvment in Octane on PPC64.
      
      R=danno@chromium.org, svenpanne@chromium.org, bmeurer@chromium.org, rmcilroy@chromium.org, dstence@us.ibm.com, michael_dawson@ca.ibm.com
      BUG=chromium:478811
      LOG=Y
      
      Review URL: https://codereview.chromium.org/1131783003
      
      Cr-Commit-Position: refs/heads/master@{#28770}
      a9404029
  9. 01 Jun, 2015 1 commit
  10. 29 May, 2015 1 commit
  11. 28 May, 2015 1 commit
  12. 21 May, 2015 1 commit
  13. 12 May, 2015 1 commit
  14. 08 May, 2015 1 commit
    • mvstanton's avatar
      TurboFan: commit dependencies only on update of the opt. code list. · f9c46ed1
      mvstanton authored
      TurboFan compilation was committing dependencies long before the
      optimized function made it's way into the optimized code list for
      the native context. The problem is that once the code pointer is out
      there in dependency arrays, it is eligible for deopt. But the deopt
      logic needs the code to be in the optimized code list to fully do it's
      job.
      
      BUG=
      R=jarin@chromium.org
      
      Review URL: https://codereview.chromium.org/1136693003
      
      Cr-Commit-Position: refs/heads/master@{#28312}
      f9c46ed1
  15. 04 May, 2015 1 commit
  16. 24 Apr, 2015 1 commit
  17. 23 Apr, 2015 1 commit
  18. 16 Apr, 2015 1 commit
  19. 15 Apr, 2015 1 commit
  20. 13 Apr, 2015 1 commit
    • vegorov's avatar
      Treat HArgumentsObject as a safe use during Uint32 analysis phase. · 021f7381
      vegorov authored
      Deoptimization infrastructure already handles it correctly.
      
      This change fixes repetitive deoptimizations in the code like this:
      
          var u32 = new Uint32Array(1);
          u32[0] = -1;
      
          function tr(x) { return x|0; }
          function ld() { return tr(u32[0]); }
      
          while (true) ld();
      
      Currently inlined tr will contain HArgumentsObject that is considered uint32-unsafe use and prevents u32[0] from becoming uint32 load - instead a speculative int32 load is generated which just deopts.
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1077113002
      
      Cr-Commit-Position: refs/heads/master@{#27781}
      021f7381
  21. 09 Mar, 2015 1 commit
    • loislo's avatar
      CpuProfiler: fix for GetDeoptReason code. · 66ab309e
      loislo authored
      The original code always returned the first entry from RelocInfo that matched with
      bailout_id. But we may have a few different deopt reasons for one bailout_id.
      So we need to get the one which matches with a particular call from JumpTable.
      
      We can do this by checking not 'target_address' (it maps to bailout_id)
      but 'from' address which maps to a particular JumpTable entry.
      
      The test was reworked so it tests identical functions against different reasons.
      
      BUG=chromium:452067
      LOG=n
      
      Review URL: https://codereview.chromium.org/984773003
      
      Cr-Commit-Position: refs/heads/master@{#27076}
      66ab309e
  22. 27 Feb, 2015 1 commit
  23. 20 Feb, 2015 1 commit
    • loislo's avatar
      CpuProfiler: eliminate cpu-profiler dependency from heap-inl.h · 8ba89cce
      loislo authored
      We accessed to cpu_profiler for tracking SharedFunctionInfo objects movements and used their addresses for generating function_id. Actually we could replace the manually generated shared_id by the pair script_id + position. In this case we can drop SharedFunctionInfo events support from cpu_profiler and remove the dependency.
      
      BTW GetCallUid was used as an unique identifier of the function on the front-end side. Actually it is a hash which might not be unique. So I renamed GetCallUid with GetHash and implemented GetFunctionId method.
      
      BUG=452067
      LOG=n
      
      Review URL: https://codereview.chromium.org/941973002
      
      Cr-Commit-Position: refs/heads/master@{#26775}
      8ba89cce
  24. 17 Feb, 2015 2 commits
  25. 11 Feb, 2015 3 commits
  26. 10 Feb, 2015 1 commit
    • loislo's avatar
      Propagate DeoptInfo to cpu-profiler · 86cae163
      loislo authored
      1) Deoptimizer::Reason was replaced with Deoptimizer::DeoptInfo
      because it also has raw position. Also the old name clashes with DeoptReason enum.
      
      2) c_entry_fp assignment call was added to EntryGenerator::Generate
      So we can calculate sp and have a chance to record the stack for the deopting function.
      btw it makes the test stable.
      
      3) new kind of CodeEvents was added to cpu-profiler
      
      4) GetDeoptInfo method was extracted from PrintDeoptLocation.
      So it could be reused in cpu profiler.
      
      BUG=452067
      LOG=n
      
      Review URL: https://codereview.chromium.org/910773002
      
      Cr-Commit-Position: refs/heads/master@{#26545}
      86cae163
  27. 05 Feb, 2015 3 commits
  28. 04 Feb, 2015 2 commits
    • loislo's avatar
      Revert of Externalize deoptimization reasons. (patchset #6 id:100001 of... · bfc5d83b
      loislo authored
      Revert of Externalize deoptimization reasons. (patchset #6 id:100001 of https://codereview.chromium.org/874323003/)
      
      Reason for revert:
      it broke the build
      
      Original issue's description:
      > Externalize deoptimization reasons.
      >
      > 1) The hardcoded strings were converted into DeoptReason enum.
      >
      > 2) Deopt comment were converted into a pair location and deopt reason entries so
      > the deopt reason tracking mode would less affect the size of the RelocInfo table and heap.
      >
      > 3) DeoptReason entry in RelocInfo reuses kCommentTag value and generates short entry in RelocInfo table.
      >
      > BUG=452067
      > LOG=n
      >
      > Committed: https://crrev.com/c49820e45b57f128a98690940875c049f612dde6
      > Cr-Commit-Position: refs/heads/master@{#26434}
      
      TBR=alph@chromium.org,mstarzinger@chromium.org,svenpanne@chromium.org,yurys@chromium.org
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=452067
      
      Review URL: https://codereview.chromium.org/892843007
      
      Cr-Commit-Position: refs/heads/master@{#26435}
      bfc5d83b
    • loislo's avatar
      Externalize deoptimization reasons. · c49820e4
      loislo authored
      1) The hardcoded strings were converted into DeoptReason enum.
      
      2) Deopt comment were converted into a pair location and deopt reason entries so
      the deopt reason tracking mode would less affect the size of the RelocInfo table and heap.
      
      3) DeoptReason entry in RelocInfo reuses kCommentTag value and generates short entry in RelocInfo table.
      
      BUG=452067
      LOG=n
      
      Review URL: https://codereview.chromium.org/874323003
      
      Cr-Commit-Position: refs/heads/master@{#26434}
      c49820e4
  29. 30 Jan, 2015 3 commits
  30. 23 Jan, 2015 1 commit
    • danno's avatar
      Remove the dependency of Zone on Isolate · c7b09aac
      danno authored
      Along the way:
      - Thread isolate parameter explicitly through code that used to
        rely on getting it from the zone.
      - Canonicalize the parameter position of isolate and zone for
        affected code
      - Change Hydrogen New<> instruction templates to automatically
        pass isolate
      
      R=mstarzinger@chromium.org
      LOG=N
      
      Review URL: https://codereview.chromium.org/868883002
      
      Cr-Commit-Position: refs/heads/master@{#26252}
      c7b09aac
  31. 07 Jan, 2015 1 commit