1. 20 Oct, 2017 1 commit
    • Hannes Payer's avatar
      [heap] Implemented write protected code pages. · 14917b65
      Hannes Payer authored
      This CL provides the basic infrastructure on the GC side for write protected code pages.
      
      The only thing missing on the GC side is the out-of-line free list implementation. In this
      CL sweeper threads and the mutator need to synchronize when page protection mode changes.
      This would not be necessary if the sweepr use and out-of-line free list.
      
      Code allocation is currently protected by a CodeSpaceMemoryModificationScope. This may
      go away with a unification of code space allocation and initialization that will happen
      later.
      
      One thing missing in this CL: freshly added pages are still read+write+executable. This
      also needs to change: WIP
      
      Bug: chromium:774108,v8:6792
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      Change-Id: Ib8d1ed1c09cc144791e462277bf43a4641e1490d
      Reviewed-on: https://chromium-review.googlesource.com/716379
      Commit-Queue: Hannes Payer <hpayer@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48774}
      14917b65
  2. 13 Oct, 2017 1 commit
  3. 23 Aug, 2017 1 commit
    • Ross McIlroy's avatar
      Reland "[Compiler] Remove code aging support." · 8bf15bf1
      Ross McIlroy authored
      > This reverts commit 42d3d36b.
      > 
      > Original change's description:
      > > [Compiler] Remove code aging support.
      > > 
      > > Code aging is no longer supported by any remaining compilers now
      > > that full codegen has been removed. This CL removes all vestiges of
      > > code aging.
      > > 
      > > BUG=v8:6409
      > > 
      > > Change-Id: I945ebcc20c7c55120550c8ee36188bfa042ea65e
      > > Reviewed-on: https://chromium-review.googlesource.com/619153
      > > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > > Reviewed-by: Marja Hölttä <marja@chromium.org>
      > > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#47501}
      > 
      > TBR=ulan@chromium.org,rmcilroy@chromium.org,marja@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,rodolph.perfetta@arm.com
      > 
      > Change-Id: I9d8b2985e2d472697908270d93a35eb7ef9c88a8
      > No-Presubmit: true
      > No-Tree-Checks: true
      > No-Try: true
      > Bug: v8:6409
      > Reviewed-on: https://chromium-review.googlesource.com/625998
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#47506}
      
      TBR=ulan@chromium.org,rmcilroy@chromium.org,marja@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,rodolph.perfetta@arm.com
      
      Change-Id: I68785c6be7686e874b3848103e3a34483eaeb519
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:6409
      Reviewed-on: https://chromium-review.googlesource.com/625919Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47535}
      8bf15bf1
  4. 22 Aug, 2017 2 commits
  5. 21 Aug, 2017 1 commit
  6. 02 Aug, 2017 1 commit
  7. 31 May, 2017 1 commit
    • neis's avatar
      [compiler] Delay allocation of code-embedded heap numbers. · 659e8f7b
      neis authored
      Instead of allocating and embedding certain heap numbers into the code
      during code assembly, emit dummies but record the allocation requests.
      Later then, in Assembler::GetCode, allocate the heap numbers and patch
      the code by replacing the dummies with the actual objects. The
      RelocInfos for the embedded objects are already recorded correctly when
      emitting the dummies.
      
      R=jarin@chromium.org
      BUG=v8:6048
      
      Review-Url: https://codereview.chromium.org/2900683002
      Cr-Commit-Position: refs/heads/master@{#45635}
      659e8f7b
  8. 20 Apr, 2017 1 commit
  9. 17 Mar, 2017 1 commit
    • neis's avatar
      Disentangle assembler from isolate. · 94b088ca
      neis authored
      This is a first step towards moving Turbofan code generation off the main thread.
      
      Summary of the changes:
      - AssemblerBase no longer has a pointer to the isolate. Instead, its
        constructor receives the few things that it needs from the isolate (on most
        architectures this is just the serializer_enabled flag).
      - RelocInfo no longer has a pointer to the isolate. Instead, the functions
        that need it take it as an argument.  (There are currently still a few that
        implicitly access the isolate through a HeapObject.)
      - The MacroAssembler now explicitly holds a pointer to the isolate (before, it
        used to get it from the Assembler).
      - The jit_cookie also moved from AssemblerBase to the MacroAssemblers, since
        it's not used at all in the Assemblers.
      - A few architectures implemented parts of the Assembler with the help
        of a Codepatcher that is based on MacroAssembler.  Since the Assembler no
        longer has the isolate, but the MacroAssembler still needs it, this doesn't
        work anymore.  Instead, these Assemblers now use a new PatchingAssembler.
      
      BUG=v8:6048
      
      Review-Url: https://codereview.chromium.org/2732273003
      Cr-Commit-Position: refs/heads/master@{#43890}
      94b088ca
  10. 19 Jan, 2017 1 commit
  11. 12 Jan, 2017 1 commit
  12. 11 Jan, 2017 2 commits
  13. 10 Jan, 2017 3 commits
  14. 29 Nov, 2016 1 commit
  15. 22 Nov, 2016 1 commit
  16. 25 Jul, 2016 1 commit
  17. 18 Jul, 2016 1 commit
  18. 17 Jun, 2016 1 commit
    • bmeurer's avatar
      [builtins] Introduce proper Float64Exp operator. · d5f2ac5e
      bmeurer authored
      Import base::ieee754::exp() from FreeBSD msun and introduce a Float64Exp
      TurboFan operator based on that, similar to what we do for Float64Log.
      Rewrite Math.exp() as TurboFan builtin and use that operator to also
      inline Math.exp() into optimized TurboFan functions.
      
      CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
      BUG=v8:3266,v8:3468,v8:3493,v8:5086,v8:5108,chromium:620786
      R=mvstanton@chromium.org
      
      Committed: https://crrev.com/93e26314afc9da9b5b8bd998688262444ed73260
      Review-Url: https://codereview.chromium.org/2077533002
      Cr-Original-Commit-Position: refs/heads/master@{#37037}
      Cr-Commit-Position: refs/heads/master@{#37047}
      d5f2ac5e
  19. 16 Jun, 2016 2 commits
  20. 26 Apr, 2016 1 commit
  21. 08 Mar, 2016 1 commit
    • danno's avatar
      [runtime] Unify and simplify how frames are marked · 9dcd0857
      danno authored
      Before this CL, various code stubs used different techniques
      for marking their frames to enable stack-crawling and other
      access to data in the frame. All of them were based on a abuse
      of the "standard" frame representation, e.g. storing the a
      context pointer immediately below the frame's fp, and a
      function pointer after that. Although functional, this approach
      tends to make stubs and builtins do an awkward, unnecessary
      dance to appear like standard frames, even if they have
      nothing to do with JavaScript execution.
      
      This CL attempts to improve this by:
      
      * Ensuring that there are only two fundamentally different
        types of frames, a "standard" frame and a "typed" frame.
        Standard frames, as before, contain both a context and
        function pointer. Typed frames contain only a minimum
        of a smi marker in the position immediately below the fp
        where the context is in standard frames.
      * Only interpreted, full codegen, and optimized Crankshaft and
        TurboFan JavaScript frames use the "standard" format. All
        other frames use the type frame format with an explicit
        marker.
      * Typed frames can contain one or more values below the
        type marker. There is new magic macro machinery in
        frames.h that simplifies defining the offsets of these fields
        in typed frames.
      * A new flag in the CallDescriptor enables specifying whether
        a frame is a standard frame or a typed frame. Secondary
        register location spilling is now only enabled for standard
        frames.
      * A zillion places in the code have been updated to deal with
        the fact that most code stubs and internal frames use the
        typed frame format. This includes changes in the
        deoptimizer, debugger, and liveedit.
      * StandardFrameConstants::kMarkerOffset is deprecated,
        (CommonFrameConstants::kContextOrFrameTypeOffset
        and StandardFrameConstants::kFrameOffset are now used
        in its stead).
      
      LOG=N
      
      Review URL: https://codereview.chromium.org/1696043002
      
      Cr-Commit-Position: refs/heads/master@{#34571}
      9dcd0857
  22. 21 Jan, 2016 1 commit
  23. 27 Nov, 2015 1 commit
  24. 26 Nov, 2015 1 commit
  25. 25 Nov, 2015 4 commits
  26. 24 Nov, 2015 1 commit
  27. 29 Sep, 2015 1 commit
  28. 03 Sep, 2015 1 commit
  29. 17 Aug, 2015 1 commit
  30. 13 Jul, 2015 1 commit
  31. 01 Jun, 2015 1 commit
  32. 22 Jan, 2015 1 commit