1. 31 Oct, 2018 1 commit
  2. 29 Oct, 2018 1 commit
  3. 24 Oct, 2018 1 commit
  4. 19 Oct, 2018 2 commits
    • Sigurd Schneider's avatar
      Revert "[embedded] Share a single RelocInfo between all trampolines" · bb54f999
      Sigurd Schneider authored
      This reverts commit 1bf6e735.
      
      Reason for revert: Breaks nosnap builds:
      https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20nosnap%20-%20debug/21209
      
      Original change's description:
      > [embedded] Share a single RelocInfo between all trampolines
      > 
      > Creates a single RelocInfo to be used by all builtin trampolines and
      > stores it as a root. All trampolines then substitute this for their
      > trampoline at generation time with DCHECKs to make sure it is
      > identical.
      > 
      > Also forces all non-trampoline RelocInfo ByteArrays for builtins to be
      > generated into RO_SPACE.
      > 
      > On x64, this results in the OLD_SPACE part of the startup snapshot
      > decreasing in size from 166096 to 131248 (-34848) bytes and RO_SPACE
      > (in the read-only snapshot) increasing from 31176 to 31248 (+72) bytes.
      > 
      > Bug: v8:8295
      > Change-Id: I69f4a899b738f2023ed42501c2b9797d34305b06
      > Reviewed-on: https://chromium-review.googlesource.com/c/1276468
      > Commit-Queue: Dan Elphick <delphick@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#56811}
      
      TBR=ulan@chromium.org,jgruber@chromium.org,delphick@chromium.org
      
      Change-Id: I57239af6f3fc9c403977da0561b8fe32c1a758e7
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:8295
      Reviewed-on: https://chromium-review.googlesource.com/c/1291070Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56814}
      bb54f999
    • Dan Elphick's avatar
      [embedded] Share a single RelocInfo between all trampolines · 1bf6e735
      Dan Elphick authored
      Creates a single RelocInfo to be used by all builtin trampolines and
      stores it as a root. All trampolines then substitute this for their
      trampoline at generation time with DCHECKs to make sure it is
      identical.
      
      Also forces all non-trampoline RelocInfo ByteArrays for builtins to be
      generated into RO_SPACE.
      
      On x64, this results in the OLD_SPACE part of the startup snapshot
      decreasing in size from 166096 to 131248 (-34848) bytes and RO_SPACE
      (in the read-only snapshot) increasing from 31176 to 31248 (+72) bytes.
      
      Bug: v8:8295
      Change-Id: I69f4a899b738f2023ed42501c2b9797d34305b06
      Reviewed-on: https://chromium-review.googlesource.com/c/1276468
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56811}
      1bf6e735
  5. 20 Sep, 2018 1 commit
    • Dan Elphick's avatar
      [interpreter] Always put bytecode handlers in builtins table · daa296b5
      Dan Elphick authored
      This always creates the bytecode handlers as part of the builtins table
      regardless of the V8_EMBEDDED_BYTECODE_HANDLERS definition.
      
      Lazy deserialization of bytecode handlers is enabled for this flow by
      moving the three lazy bytecode deserializers from the strong roots into
      the builtins table (ensuring that they not marked lazy themselves).
      
      To simplify lazy deserialization, the illegal bytecode handler is made
      non-lazy so that GetAndMaybeDeserializeBytecodeHandler doesn't to know
      about it.
      
      Since the bytecode handlers are now always part of the builtins table,
      many bytecode specific methods are removed, including logging and in
      BuiltinsSerializer and BuiltinsDeserializer.
      
      Removes setup-interpreter.h, setup-interpreter-internal.cc and
      builtin-snapshot-utils.*.
      
      Change-Id: Ie421aa897a04f7b3bcb964c476eb7ab149388d53
      Reviewed-on: https://chromium-review.googlesource.com/1220046Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56063}
      daa296b5
  6. 14 Sep, 2018 1 commit
    • Jakob Gruber's avatar
      Revert "[builtins] Add FastCallFunction builtin that elides some checks" · 74320a1b
      Jakob Gruber authored
      This reverts commit 99e13e58.
      
      Reason for revert: Reverting in favor of a general mechanism for this in Torque.
      
      Original change's description:
      > [builtins] Add FastCallFunction builtin that elides some checks
      > 
      > This CL adds a new "Call" stub that can be used by builtins that will
      > call the same JS call-back function often (e.g. compare function in
      > Array.p.sort). The checks have to be done upfront once, but can then
      > be omitted.
      > 
      > R=​jgruber@chromium.org
      > 
      > Bug: v8:7861
      > Change-Id: Id6e4ca27c3d488a7b1f708cbcb4cbe6cc382513e
      > Reviewed-on: https://chromium-review.googlesource.com/1208574
      > Commit-Queue: Simon Zünd <szuend@google.com>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Camillo Bruni <cbruni@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#55769}
      
      TBR=cbruni@chromium.org,jgruber@chromium.org,szuend@google.com
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: v8:7861
      Change-Id: I47260993ef2a16bd5348bb0b46da4d34d33ea10b
      Reviewed-on: https://chromium-review.googlesource.com/1226871
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55897}
      74320a1b
  7. 11 Sep, 2018 1 commit
  8. 10 Sep, 2018 1 commit
    • Dan Elphick's avatar
      [embedded handlers] Store the handlers without gaps · 5a9f0556
      Dan Elphick authored
      Previously the builtins table had a value for every single
      OperandScale/Bytecode combination regardless of whether it was valid.
      This change makes it so that only valid bytecode handlers are stored in
      the builtins table. This prevents placeholders being serialized into the
      snapshot (and embedded into the binary) saving 9KB in
      CODE_SPACE/OLD_SPACE and 2.5KB in the embedded data as well as 66
      entries in the builtins table.
      
      To do this, it generates a new header file bytecodes-builtins-list.h
      which is created from the BYTECODE_LIST and OPERAND_SCALE_LIST macros.
      Since list macros cannot be used to conditionally generate elements in
      the C-preprocessor, this is done by generator executable, compiled from
      interpreter/generate-flat-headers.cc.
      
      Additionally the generator creates the flat bytecode list so that it is
      transposed from the previous result, i.e. the results are grouped by
      bytecode and then operand scale rather than operand scale then bytecode.
      This should give better locality for commonly used bytecodes and may
      allow less commonly used ExtraWide bytecodes to never be mapped into
      memory at all.
      
      The cost to storing the handlers densely is that looking up a handler
      now requires a binary search through the builtins table, but this should
      only happen during debugging. It is also fixable at least for non-wide
      handlers and could be improved for wide ones if the need arises.
      
      Bug: v8:8068
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
      Change-Id: Iaad22a952e2858f508030c5ddc082f91bf59f667
      Reviewed-on: https://chromium-review.googlesource.com/1209304
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55757}
      5a9f0556
  9. 03 Sep, 2018 1 commit
  10. 22 Aug, 2018 1 commit
  11. 21 Aug, 2018 1 commit
    • Dan Elphick's avatar
      Reland "[builtins] Start adding byte code handlers to builtins" · fe5e07d7
      Dan Elphick authored
      This is a reland of 041ae1f8
      
      The clashing method has been fixed.
      
      Original change's description:
      > [builtins] Start adding byte code handlers to builtins
      >
      > Adds a new build flag, v8_enable_embedded_bytecode_handlers, that adds
      > the bytecode handlers to the BUILTIN_LIST macros.
      >
      > Currently it's not connected up to the code-generation so it actually
      > does nothing except expand the builtins table.
      >
      > Bug: v8:8068
      > Change-Id: Iaecc3982cf22d04e6c46169b86c9d694952fd091
      > Reviewed-on: https://chromium-review.googlesource.com/1179887
      > Commit-Queue: Dan Elphick <delphick@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#55215}
      
      Bug: v8:8068
      Change-Id: Ibc98929a9ad464e9d4c9fc7d43401f0fb0df9a00
      Reviewed-on: https://chromium-review.googlesource.com/1181981Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55244}
      fe5e07d7
  12. 20 Aug, 2018 2 commits
    • Dan Elphick's avatar
      Revert "[builtins] Start adding byte code handlers to builtins" · 737ffec5
      Dan Elphick authored
      This reverts commit 041ae1f8.
      
      Reason for revert: Causes jumbo builds to fail because of duplicate GenerateBytecodeHandler definitions.
      
      Original change's description:
      > [builtins] Start adding byte code handlers to builtins
      > 
      > Adds a new build flag, v8_enable_embedded_bytecode_handlers, that adds
      > the bytecode handlers to the BUILTIN_LIST macros.
      > 
      > Currently it's not connected up to the code-generation so it actually
      > does nothing except expand the builtins table.
      > 
      > Bug: v8:8068
      > Change-Id: Iaecc3982cf22d04e6c46169b86c9d694952fd091
      > Reviewed-on: https://chromium-review.googlesource.com/1179887
      > Commit-Queue: Dan Elphick <delphick@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#55215}
      
      TBR=rmcilroy@chromium.org,jgruber@chromium.org,delphick@chromium.org
      
      Change-Id: I860b3ecf543944fd0f4fdcb8de09d21a4b784150
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:8068
      Reviewed-on: https://chromium-review.googlesource.com/1181301Reviewed-by: 's avatarDan Elphick <delphick@chromium.org>
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55225}
      737ffec5
    • Dan Elphick's avatar
      [builtins] Start adding byte code handlers to builtins · 041ae1f8
      Dan Elphick authored
      Adds a new build flag, v8_enable_embedded_bytecode_handlers, that adds
      the bytecode handlers to the BUILTIN_LIST macros.
      
      Currently it's not connected up to the code-generation so it actually
      does nothing except expand the builtins table.
      
      Bug: v8:8068
      Change-Id: Iaecc3982cf22d04e6c46169b86c9d694952fd091
      Reviewed-on: https://chromium-review.googlesource.com/1179887
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55215}
      041ae1f8
  13. 03 Jul, 2018 1 commit
  14. 22 Jun, 2018 1 commit
  15. 05 Jun, 2018 1 commit
    • jgruber's avatar
      [builtins] Move builtins table to the Heap class · e3e3480b
      jgruber authored
      The builtins table is an array of pointers to builtin code objects. It
      used to be located within the Builtins class, which itself was part of
      the Isolate.
      
      To enable faster isolate-independent access to builtin code objects,
      this CL moves the builtins table into the heap, at a constant known
      offset from the roots table. With this change, builtins can be accessed
      through the root pointer with a single instruction:
      
       mov reg, [kRootPointer, <offset to builtin>]
      
      TurboAssembler::LookupConstant is also extended in this CL to
      potentially shortcut the slow-ish constants table lookup: root
      constants are loaded through the root list, and builtin constants
      through the builtins table.
      
      Bug: v8:6666
      Change-Id: I8e83c2a8783c01ebece89483274f42ab4c8872f2
      Reviewed-on: https://chromium-review.googlesource.com/1075275
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53528}
      e3e3480b
  16. 25 May, 2018 1 commit
  17. 07 May, 2018 1 commit
    • jgruber's avatar
      [builtins] Convert CEntry/GetProperty/StringAdd stubs to builtins · d8131cd6
      jgruber authored
      Stubs and builtins are very similar. The main differences are that
      stubs can be parameterized and may be generated at runtime, whereas
      builtins are generated at mksnapshot-time and shipped with the snapshot
      (or embedded into the binary).
      
      My main motivation for these conversions is that we can generate
      faster calls and jumps to (embedded) builtins callees from (embedded)
      builtin callers. Instead of going through the builtins constants table
      indirection, we can simply do a pc-relative call/jump.
      
      This also unlocks other refactorings, e.g. removal of
      CallRuntimeDelayed.
      
      TBR=mlippautz@chromium.org
      
      Bug: v8:6666
      Change-Id: I4cd63477f19a330ec70bbf20e2af8a42fb05fabb
      Reviewed-on: https://chromium-review.googlesource.com/1044245Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53027}
      d8131cd6
  18. 14 Apr, 2018 1 commit
    • Jakob Kummerow's avatar
      [ubsan] Change Address typedef to uintptr_t · 2459046c
      Jakob Kummerow authored
      The "Address" type is V8's general-purpose type for manipulating memory
      addresses. Per the C++ spec, pointer arithmetic and pointer comparisons
      are undefined behavior except within the same array; since we generally
      don't operate within a C++ array, our general-purpose type shouldn't be
      a pointer type.
      
      Bug: v8:3770
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
      Change-Id: Ib96016c24a0f18bcdba916dabd83e3f24a1b5779
      Reviewed-on: https://chromium-review.googlesource.com/988657
      Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52601}
      2459046c
  19. 09 Apr, 2018 2 commits
  20. 26 Mar, 2018 1 commit
    • jgruber's avatar
      [builtins] Support off-heap constant pool access · 4c5bf68e
      jgruber authored
      Access to the constant pool of off-heap builtins must use
      Instruction{Start,Size} instead of the raw instruction_{start,size}
      accessors, and we need to copy the constant_pool_offset field when
      creating trampolines.
      
      This in turn required access to the embedded blob without an
      associated isolate, which is now implemented by global variable set by
      each isolate. Both writes and reads are relaxed, as races do not
      matter since each isolate will attempt to set the same value of the
      blob and its size.
      
      Drive-by: Support off-heap code disassembly.
      
      Bug: v8:6666,v8:7575
      Change-Id: I4f203acd4dc128339cf2dd54b3253d9552616649
      Reviewed-on: https://chromium-review.googlesource.com/973442
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52209}
      4c5bf68e
  21. 19 Mar, 2018 1 commit
    • jgruber's avatar
      Reland "[builtins] Remove off-heap builtins from the snapshot" · fd70917d
      jgruber authored
      This is a reland of f1b1ec70
      
      Original change's description:
      > [builtins] Remove off-heap builtins from the snapshot
      >
      > This CL is the final major step towards shipping off-heap-safe builtins
      > embedded into the binary.
      >
      > Prior to snapshot serialization, we now:
      > * create the embedded blob containing off-heap instruction streams,
      > * use that to generate embedded.cc (containing embedded binary data),
      > * replace off-heap-safe builtins with trampolines,
      > * and serialize those into the final snapshot.
      >
      > The new RelocInfo::OFF_HEAP_TARGET kind is used to fix up trampoline
      > targets on deserialization.
      >
      > Bug: v8:6666
      > Change-Id: Ib07aea9e3bd7ecdec42291c1388b3a7453ea96ce
      > Reviewed-on: https://chromium-review.googlesource.com/950775
      > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#51960}
      
      TBR=yangguo@chromium.org,mstarzinger@chromium.org
      
      Cq-Include-Trybots: luci.v8.try:v8_mac64_dbg,v8_mac64_rel
      Bug: v8:6666
      Change-Id: Id9954af3c8195754ff3658c4603858904fcf88c4
      Reviewed-on: https://chromium-review.googlesource.com/964481
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52006}
      fd70917d
  22. 15 Mar, 2018 2 commits
  23. 26 Feb, 2018 2 commits
  24. 23 Feb, 2018 1 commit
    • jgruber's avatar
      [builtins] Add IsOffHeapSafe predicate and test · 481c21e0
      jgruber authored
      Off-heap-safety slightly differs from isolate-independence in that it
      allows external references and checks instruction-size constraints.
      
      This adds the new predicate as well as a cctest verifying it. New
      DCHECKs are introduced to document assumptions and upcoming work.
      
      Note that this breaks the --stress-off-heap-code flag. Fixes will
      follow in upcoming CLs.
      
      Bug: v8:6666
      Change-Id: If4f3e0f4428bacc8d293cd864b9b07b81679c423
      Reviewed-on: https://chromium-review.googlesource.com/934183
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51513}
      481c21e0
  25. 30 Jan, 2018 1 commit
  26. 08 Nov, 2017 1 commit
    • jgruber's avatar
      [factory] Simplify JSFunction creation · 72230246
      jgruber authored
      There's three common situations in which we need to create JSFunction
      objects.  1) from the compiler, 2) from tests, and 3) everything else
      (mostly during bootstrapping).
      
      This is an attempt to simplify case 3), which previously relied on
      several Factory::NewFunction overloads where it was not clear how the
      semantics of each overload differed.
      
      This CL removes all but one overload, and packs arguments into a new
      NewFunctionArgs helper class.
      
      It also removes the hacks around
      SFI::set_lazy_deserialization_builtin_id by explicitly passing
      builtin_id into Factory::NewSharedFunctionInfo.
      
      Drive-by-fix: Properly set is_constructor hint in
      SimpleCreateSharedFunctionInfo.
      
      Bug: v8:6624
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      Change-Id: Ica94d95e72e443055db5e7ff9e8cdf4115201ef1
      Reviewed-on: https://chromium-review.googlesource.com/757094
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49224}
      72230246
  27. 25 Sep, 2017 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Properly optimize literals in inlined functions. · 855b88ae
      Benedikt Meurer authored
      When inlining based on SharedFunctionInfo rather than based on concrete
      JSFunction, we weren't able to properly optimize array, object and
      regexp literals inside the inlinee, because we didn't know the concrete
      FeedbackVector for the inlinee inside JSCreateLowering. This was because
      JSCreateLowering wasn't properly updated after the literals moved to the
      FeedbackVector. Now with this CL we also have the VectorSlotPair on the
      literal creation operators, just like we do for property accesses and
      calls, and are thus able to always access the appropriate FeedbackVector
      and optimize the literal creation.
      
      The impact is illustrated by the micro-benchmark on the tracking bug,
      which goes from
      
        createEmptyArrayLiteral: 1846 ms.
        createShallowArrayLiteral: 1868 ms.
        createShallowObjectLiteral: 2246 ms.
      
      to
      
        createEmptyArrayLiteral: 1175 ms.
        createShallowArrayLiteral: 1187 ms.
        createShallowObjectLiteral: 1195 ms.
      
      with this CL, so up to 2x faster now.
      
      Drive-by-fix: Also remove the unused CreateEmptyObjectLiteral builtin
      and cleanup the names of the other builtins to be consistent with the
      names of the TurboFan operators and Ignition bytecodes.
      
      Bug: v8:6856
      Change-Id: I453828d019b27c9aa1344edac0dd84e91a457097
      Reviewed-on: https://chromium-review.googlesource.com/680656
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48140}
      855b88ae
  28. 05 Sep, 2017 2 commits
    • jgruber's avatar
      [builtins] Remove most Builtins::Name usages in API · 0e4f6007
      jgruber authored
      Using the Builtins::Name type doesn't give use any range safety benefits
      over simply using int id's, and it complicates use sites by always
      forcing a static_cast<Builtins::Name>(id).
      
      Bug: v8:6624
      Change-Id: Id5fcf6800c781c637145ab1d00d821f9ad473321
      Reviewed-on: https://chromium-review.googlesource.com/650247
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47823}
      0e4f6007
    • jgruber's avatar
      [builtins] Implement lazy deserialization for TFJ builtins · 79aee245
      jgruber authored
      This adds support for lazy deserialization of JS-linkage (TFJ) builtins,
      still gated behind the --lazy-deserialization flag. If enabled, we
      proceed as follows:
      
      During isolate initialization, only eager builtins are deserialized. All
      references to lazy builtins are replaced by the DeserializeLazy builtin.
      In particular, this happens in the builtin table (Builtins::builtins_)
      and in SharedFunctionInfo objects.
      
      When calling into a not-yet deserialized function (i.e. the JSFunction's
      code object is the DeserializeLazy builtin), the DeserializeLazy builtin
      takes over.  It checks the builtin table to see if the target builtin
      (determined by looking at the builtin id stored on the
      SharedFunctionInfo) has already been deserialized. If so, it simply
      copies the builtin code object to the JSFunction and SharedFunctionInfo.
      Otherwise, we enter Runtime::kDeserializeLazy to deserialize the
      builtin.
      
      With --lazy-deserialization, isolate deserialization is 11% faster
      (1.5ms vs.  1.7ms), and code_space->Size() is 33% lower (984K vs.
      1475K).
      
      Moving relocation infos & handler tables out of the partial snapshot
      cache would additionally let us save up to 30K per isolate. Adding code
      stubs to that list increases further potential savings to 262K.
      
      Bug: v8:6624
      Change-Id: I0ac7d05d165d2466998269bd431ac076a311cbeb
      Reviewed-on: https://chromium-review.googlesource.com/649166
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47818}
      79aee245
  29. 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
  30. 30 Aug, 2017 1 commit
  31. 16 Aug, 2017 1 commit
  32. 07 Aug, 2017 1 commit
  33. 01 Aug, 2017 1 commit
    • jgruber's avatar
      Reland "[builtins] Remove Builtins::Name() accessors" · fcaa2c2e
      jgruber authored
      This is a reland of 2f79e035
      Original change's description:
      > [builtins] Remove Builtins::Name() accessors
      > 
      > Instead of auto-generating the Name() convenience accessor, use a macro to
      > avoid wasting code space.
      > 
      >   BUILTIN_CODE(isolate, Name)
      > 
      > expands to
      > 
      >   isolate->builtins()->builtin_handle(Builtins::kName);
      > 
      > This reduces the size of libv8.so by 134,752 bytes on a x64 release build.
      > 
      > Bug: v8:6624
      > Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      > Change-Id: Idff7ee5c45e344e73412c0f47e92553c7c7ff75f
      > Reviewed-on: https://chromium-review.googlesource.com/593607
      > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
      > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#47010}
      
      TBR=bmeurer@chromium.org,ahaas@chromium.org
      
      Bug: v8:6624
      Change-Id: I4733731e56dc8873ee06c2b36cac1918c0a658b2
      Reviewed-on: https://chromium-review.googlesource.com/594087
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47037}
      fcaa2c2e
  34. 31 Jul, 2017 1 commit
    • Jakob Gruber's avatar
      Revert "[builtins] Remove Builtins::Name() accessors" · 17a26c0b
      Jakob Gruber authored
      This reverts commit 2f79e035.
      
      Reason for revert: Conflicts with successor CL.
      
      Original change's description:
      > [builtins] Remove Builtins::Name() accessors
      > 
      > Instead of auto-generating the Name() convenience accessor, use a macro to
      > avoid wasting code space.
      > 
      >   BUILTIN_CODE(isolate, Name)
      > 
      > expands to
      > 
      >   isolate->builtins()->builtin_handle(Builtins::kName);
      > 
      > This reduces the size of libv8.so by 134,752 bytes on a x64 release build.
      > 
      > Bug: v8:6624
      > Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      > Change-Id: Idff7ee5c45e344e73412c0f47e92553c7c7ff75f
      > Reviewed-on: https://chromium-review.googlesource.com/593607
      > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
      > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#47010}
      
      TBR=yangguo@chromium.org,ahaas@chromium.org,jgruber@chromium.org,bmeurer@chromium.org
      
      Change-Id: Ia9ef5c755b26c3f4e143d87a7c51033614ea435e
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:6624
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/594048Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47012}
      17a26c0b