- 21 May, 2020 1 commit
-
-
Seth Brenith authored
Currently, if d8 is run with the --turbo-profiling flag, it prints info about every TurboFan-compiled function. This info includes the number of times that each basic block in the function was run. It also includes text representations of the function's schedule and code, so that the person reading the output can associate counters with blocks of code. The data about each function is currently stored in a BasicBlockProfiler::Data instance, which is attached to a list owned by the singleton BasicBlockProfiler. Each Data contains an std::vector<uint32_t> which represents how many times each block in the function has executed. The generated code for each block uses a raw pointer into the storage of that vector to implement incrementing the counter. With this change, if you compile with v8_enable_builtins_profiling and then run with --turbo-profiling, d8 will print that same info about builtins too. In order to generate code that can survive being serialized to a snapshot and reloaded, this change uses counters in the JS heap instead of a std::vector outside the JS heap. The steps for instrumentation are as follows: 1. Between scheduling and instruction selection, add code to increment the counter for each block. The counters array doesn't yet exist at this point, and allocation is disallowed, so at this point the code refers to a special marker value. 2. During finalization of the code, allocate a BasicBlockProfilingData object on the JS heap containing data equivalent to what is stored in BasicBlockProfiler::Data. This includes a ByteArray that is big enough to store the counters for each block. 3. Patch the reference in the BuiltinsConstantsTableBuilder so that instead of referring to the marker object, it now refers to this ByteArray. Also add the BasicBlockProfilingData object to a list that is attached to the heap roots so it can be easily accessed for printing. Because these steps include modifying the BuiltinsConstantsTableBuilder, this procedure is only applicable to builtins. Runtime-generated code still uses raw pointers into std::vector instances. In order to keep divergence between these code paths to a minimum, most work is done referring to instances of BasicBlockProfiler::Data (the C++ class), and functions are provided to copy back and forth between that type and BasicBlockProfilingData (the JS heap object). This change is intended only to make --turbo-profiling work consistently on more kinds of functions, but with some further work, this data could form the basis for: - code coverage info for fuzzers, and/or - hot-path info for profile-guided optimization. Bug: v8:10470, v8:9119 Change-Id: Ib556a5bc3abe67cdaa2e3ee62702a2a08b11cb61 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2159738 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#67944}
-
- 24 May, 2019 1 commit
-
-
Yang Guo authored
TBR=mvstanton@chromium.org,neis@chromium.org,ahaas@chromium.org Bug: v8:9247 Change-Id: I5433c863a54f3412d73df0d38aba3fdbcfac7ebe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627973 Commit-Queue: Yang Guo <yangguo@chromium.org> Auto-Submit: Yang Guo <yangguo@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#61830}
-
- 23 May, 2019 1 commit
-
-
Clemens Hammacher authored
This CL was generated by an automatic clang AST rewriter using this matcher expression: callExpr( callee( cxxMethodDecl( hasName("operator->"), ofClass(isSameOrDerivedFrom("v8::internal::Object")) ) ), argumentCountIs(1) ) The "->" at the expression location was then rewritten to ".". R=jkummerow@chromium.org TBR=mstarzinger@chromium.org,verwaest@chromium.org,yangguo@chromium.org Bug: v8:9183, v8:3770 No-Try: true No-Tree-Checks: true Change-Id: I0a7ecabdeafe51d0cf427f5280af0c7cab96869e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1624209Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#61764}
-
- 22 May, 2019 1 commit
-
-
Yang Guo authored
Bug: v8:9247 Change-Id: I79e0553e8a0d6dac2aa16b94a6c0e05b6ccde4a1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1621934 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#61725}
-
- 12 Mar, 2019 1 commit
-
-
Hannes Payer authored
Bug: v8:8945 Change-Id: I14ca4b29f1b12ff95e718d431f65d88ab1238c53 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1511478Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Hannes Payer <hpayer@chromium.org> Cr-Commit-Position: refs/heads/master@{#60177}
-
- 11 Mar, 2019 1 commit
-
-
Clemens Hammacher authored
The {id_} stored in {ThreadId} should not be atomic. Only getting a new id for the current thread needs to be atomic. If any user of {ThreadId} needs atomicity, that user should wrap {ThreadId} in a {std::atomic} instead. Drive-by: Remove {Equals} method, use {operator==} instead. Drive-by: Move static methods after member methods. R=ishell@chromium.org Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel Bug: v8:8834 Change-Id: Id0470eb2fa907948843ac1153e2dc5dcd9a8fbc8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1494006Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#60146}
-
- 25 Feb, 2019 1 commit
-
-
Jakob Gruber authored
to IsGeneratingEmbeddedBuiltins() to clarify its meaning. Bug: v8:6666 Change-Id: I8b282f29775a103a03f502c3e9629b40b4a690bd Reviewed-on: https://chromium-review.googlesource.com/c/1480380Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#59815}
-
- 23 Jan, 2019 1 commit
-
-
Jakob Gruber authored
Code object iteration was missing logic for RELATIVE_CODE_TARGET reloc entries. Garbage collection could thus miss objects that were referenced only as targets of pc-relative calls or jumps. RELATIVE_CODE_TARGETs are only used on arm, mips, and s390 and only at mksnapshot-time. This exposed another issue in that the interpreter entry trampoline copy we generate for profiling *did* contain relative calls in runtime-accessible code. This is a problem, since code space on arm is, by default, too large to be fully addressable through pc-relative calls. This CL thus also disables the related FLAG_interpreted_frames_native_stack feature on arm. Drive-by: Ensure the builtins constants table does not contain Code objects. Bug: v8:8713,v8:6666 Change-Id: Idd914b46970ad08f9091fc72113fa7aed2732e71 Reviewed-on: https://chromium-review.googlesource.com/c/1424866Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#59023}
-
- 26 Dec, 2018 1 commit
-
-
Jakob Kummerow authored
Tbr: ahaas@chromium.org,leszeks@chromium.org,verwaest@chromium.org Bug: v8:3770 Change-Id: Ia6530fbb70dac05e9972283781c3550d8b50e1eb Reviewed-on: https://chromium-review.googlesource.com/c/1390116 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Alexei Filippov <alph@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#58470}
-
- 18 Dec, 2018 1 commit
-
-
Jakob Kummerow authored
Bug: v8:5402 Change-Id: Ib2d7b24cdcf55e3dfa8d3b1665ac565904ac2112 Reviewed-on: https://chromium-review.googlesource.com/c/1379940Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#58336}
-
- 11 Dec, 2018 1 commit
-
-
Jakob Gruber authored
This: - documents removal of Code's stub key field. - removes SerializedCodeData's CodeStubKeys field. - removes masm's custom self-reference marker mechanism. Bug: v8:7777 Change-Id: Ie5c51bc895e508acdeb3994cf5558a2cf4c21540 Reviewed-on: https://chromium-review.googlesource.com/c/1367744 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#58145}
-
- 26 Nov, 2018 1 commit
-
-
Marja Hölttä authored
- Remove heap-inl.h includes from places where it looked unnecessary. (This is a non-scientific approach, because it's probably pulled in indirectly anyway.) - Annotate places which include heap-inl.h because they need heap/ internals. - ACCESSORS legitimately needs heap-inl.h because of Heap::FromWritableHeapObject. - Add includes to heap/heap-write-barrier(-inl).h - A bunch of IWYU fixes discovered when working on this CL (includes which were missing because heap-inl.h pulls them in indirectly). BUG=v8:7490,v8:8238,v8:8499 Change-Id: I00f9a74d430f13d7c080dca77a92b03bcca7ef96 Reviewed-on: https://chromium-review.googlesource.com/c/1349241Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#57814}
-
- 15 Nov, 2018 3 commits
-
-
Jakob Gruber authored
This is a reland of bf2f0a02 Original change's description: > [builtins] Support embedded builtins in nosnapshot builds > > This CL adds support for embedded builtins in nosnap builds by creating > and setting an 'embedded blob' after builtin generation. Unlike > snapshot builds, the blob is not embedded into the .text section but > located on the C++ heap. > > This makes nosnap builds more consistent with mksnapshot, and allows us > to simplify there and in serializer cctests. > > Complications arise from the different workflows we need to support: > > 1. the standard mksnapshot build process, > 2. nosnap builds (which reuse the blob created by the first Isolate), > 2. and tests with various complicated serialization workflows. > > To cover all of these cases, this CL introduces two knobs to twiddle: > > 1. A 'sticky' embedded blob which overrides compiled-in default > embedded blobs at Isolate setup. > 2. The blob lifecycle can be managed manually or through refcounting. > > These are described in more detail in isolate.cc. > > Tbr: ulan@chromium.org > Bug: v8:6666, v8:8350 > Change-Id: I3842e40cdaf45d2cadd05c6eb1ec2f5e3d83568d > Reviewed-on: https://chromium-review.googlesource.com/c/1310195 > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#57523} Tbr: ulan@chromium.org,yangguo@chromium.org Bug: v8:6666, v8:8350 Change-Id: I13b523c9e7406b39a3cd28465c06f17f1744a738 Reviewed-on: https://chromium-review.googlesource.com/c/1337578 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#57540}
-
Jakob Gruber authored
This reverts commit bf2f0a02. Reason for revert: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20nosnap%20-%20debug/21753 Original change's description: > [builtins] Support embedded builtins in nosnapshot builds > > This CL adds support for embedded builtins in nosnap builds by creating > and setting an 'embedded blob' after builtin generation. Unlike > snapshot builds, the blob is not embedded into the .text section but > located on the C++ heap. > > This makes nosnap builds more consistent with mksnapshot, and allows us > to simplify there and in serializer cctests. > > Complications arise from the different workflows we need to support: > > 1. the standard mksnapshot build process, > 2. nosnap builds (which reuse the blob created by the first Isolate), > 2. and tests with various complicated serialization workflows. > > To cover all of these cases, this CL introduces two knobs to twiddle: > > 1. A 'sticky' embedded blob which overrides compiled-in default > embedded blobs at Isolate setup. > 2. The blob lifecycle can be managed manually or through refcounting. > > These are described in more detail in isolate.cc. > > Tbr: ulan@chromium.org > Bug: v8:6666, v8:8350 > Change-Id: I3842e40cdaf45d2cadd05c6eb1ec2f5e3d83568d > Reviewed-on: https://chromium-review.googlesource.com/c/1310195 > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#57523} TBR=ulan@chromium.org,yangguo@chromium.org,jgruber@chromium.org Change-Id: I6e35a0cb7186fb50f1012f5c618fb8b48b24a813 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:6666, v8:8350 Reviewed-on: https://chromium-review.googlesource.com/c/1337577Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#57529}
-
Jakob Gruber authored
This CL adds support for embedded builtins in nosnap builds by creating and setting an 'embedded blob' after builtin generation. Unlike snapshot builds, the blob is not embedded into the .text section but located on the C++ heap. This makes nosnap builds more consistent with mksnapshot, and allows us to simplify there and in serializer cctests. Complications arise from the different workflows we need to support: 1. the standard mksnapshot build process, 2. nosnap builds (which reuse the blob created by the first Isolate), 2. and tests with various complicated serialization workflows. To cover all of these cases, this CL introduces two knobs to twiddle: 1. A 'sticky' embedded blob which overrides compiled-in default embedded blobs at Isolate setup. 2. The blob lifecycle can be managed manually or through refcounting. These are described in more detail in isolate.cc. Tbr: ulan@chromium.org Bug: v8:6666, v8:8350 Change-Id: I3842e40cdaf45d2cadd05c6eb1ec2f5e3d83568d Reviewed-on: https://chromium-review.googlesource.com/c/1310195Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#57523}
-
- 11 Oct, 2018 1 commit
-
-
Igor Sheludko authored
... containing RootsTable, ExternalReferenceTable, builtins array and potentially some other data that can be accessed via the RootRegister. This is a preliminary step before adding support for pointer-compression friendly heap layout. Bug: v8:8182 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I2899f657aaff1351a5304afa0b1a4c5ae4cfc31d Reviewed-on: https://chromium-review.googlesource.com/c/1245426Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ben Titzer <titzer@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#56551}
-
- 10 Oct, 2018 1 commit
-
-
Igor Sheludko authored
... and remove Heap::RootCanBeWrittenAfterInitialization() and Heap::RootCanBeTreatedAsConstant() in favour of RootsTable::IsImmortalImmovable(). Bug: v8:8238 Change-Id: I804d06136de9584b8c4940fd8ab9d18fb3ef7980 Reviewed-on: https://chromium-review.googlesource.com/c/1270837 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#56500}
-
- 20 Sep, 2018 1 commit
-
-
Igor Sheludko authored
and introduce RootsTable - a V8 heap roots storage. So, the renaming part looks like this: Heap::RootListIndex -> RootIndex Heap::kBlahBlahRootIndex -> RootIndex::kBlahBlah Bug: v8:8015, v8:8182 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I38e1f3e3f6813ef35e37b0bed35e9ae14a62134f Reviewed-on: https://chromium-review.googlesource.com/1234613Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#56067}
-
- 20 Aug, 2018 1 commit
-
-
jgruber authored
This CL prepares the way for adding a root register on ia32. The new register allocation configuration PreserveRootIA32 treats kRootRegister as an unallocatable register. Note that kRootRegister (on ia32) is still completely unused, unallocated, and may be clobbered at many points. This is left to future work. Bug: v8:6666 Change-Id: I4aacdf9c3bb365d6ed49fea8f013f79b7b1f0a98 Reviewed-on: https://chromium-review.googlesource.com/1181023Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#55224}
-
- 03 Jul, 2018 1 commit
-
-
Dan Elphick authored
In future the RO_SPACE root accessors in Heap will become private, so instead convert them all to use ReadOnlyRoots. Bug: v8:7786 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I2cc63ffc5b6df537fa7772356acd9e8b3cf59352 Reviewed-on: https://chromium-review.googlesource.com/1124322 Commit-Queue: Dan Elphick <delphick@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#54181}
-
- 25 May, 2018 1 commit
-
-
jgruber authored
This addresses one of the major remaining slowdowns with embedded builtins on x64. When generating code for a call to a builtin callee from a builtin caller, we'd look up the Code target object from the builtins constant list, calculate the location of the first instruction, and jump to it. Note that for embedded builtin callees, the Code object is itself only a trampoline to the off-heap code and thus an additional indirection. An example of the call sequence in pseudo-asm: // Load from the constants list. mov reg, [kRootPointer, kBuiltinsConstantListOffset] mov reg, [reg, offset_of_the_code_constant] // Calculate first instruction and call it. add reg, Code::kHeaderOffset call reg // The trampoline forwards to the off-heap area. mov kOffHeapTrampolineRegister, <off-heap instruction_start> jmp kOffHeapTrampolineRegister This CL changes calls to embedded builtin targets to use pc-relative addressing. This reduces the above instruction sequence to: call <pc-relative offset to target instruction_start> Embedded-to-embedded calls jump directly to the embedded instruction stream, bypassing the trampoline. Heap-to-embedded calls (and all calls to heap-builtins) use pc-relative addressing targeting the on-heap Code object. Other relevant platforms (arm,arm64,mips,mips64) do not use pc-relative calls. For these, we'll need a different solution, e.g. a table of embedded builtin addresses reachable from the root pointer, similar to the external reference table. Bug: v8:6666 Change-Id: Ic0317d454e2da37d74eaecebcdfcbc0d5f5041ad Reviewed-on: https://chromium-review.googlesource.com/1068732 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#53349}
-
- 07 May, 2018 1 commit
-
-
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: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#53027}
-
- 02 May, 2018 1 commit
-
-
jgruber authored
Original CL: https://crrev.com/c/1018468 During code generation, we generate self-references (i.e. references to the Code object currently being generated) as references to a temporary handle. When the final Code object has been allocated, the handle's location is fixed up and RelocInfo iteration fixes up all references embedded in the generated code. This adds support for this mechanism to the builtins constants table builder. CodeObject() is now a new handle pointing to a dedicated self-reference marker in order to distinguish between self-references and references to undefined. In Factory::NewCode, we patch up the constants table. TBR=yangguo@chromium.org,mlippautz@chromium.org Bug: v8:6666 Change-Id: I3fa422c57de99c9851dc7a86394a8387c7c2b397 Reviewed-on: https://chromium-review.googlesource.com/1039366 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#52916}
-
- 27 Apr, 2018 2 commits
-
-
Michael Achenbach authored
This reverts commit 6379e2a4. Reason for revert: https://logs.chromium.org/v/?s=chromium%2Fbb%2Fclient.v8%2FV8_Win64%2F23855%2F%2B%2Frecipes%2Fsteps%2FCheck%2F0%2Flogs%2Fmkgrokdump%2F0 Original change's description: > [builtins] Patch self-references in constants table > > During code generation, we generate self-references (i.e. references to > the Code object currently being generated) as references to a temporary > handle. When the final Code object has been allocated, the handle's > location is fixed up and RelocInfo iteration fixes up all references > embedded in the generated code. > > This adds support for this mechanism to the builtins constants table > builder. CodeObject() is now a new handle pointing to a dedicated > self-reference marker in order to distinguish between self-references > and references to undefined. In Factory::NewCode, we patch up > the constants table. > > Bug: v8:6666 > Change-Id: If74ed91bb1c3b8abb20ff2f0a87d1bcd9a1b0511 > Reviewed-on: https://chromium-review.googlesource.com/1018468 > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Cr-Commit-Position: refs/heads/master@{#52854} TBR=yangguo@chromium.org,mlippautz@chromium.org,jgruber@chromium.org Change-Id: I8cf8c4b43f51285ea913c6c8fdd339bd9ea645df No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:6666 Reviewed-on: https://chromium-review.googlesource.com/1033092Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#52856}
-
jgruber authored
During code generation, we generate self-references (i.e. references to the Code object currently being generated) as references to a temporary handle. When the final Code object has been allocated, the handle's location is fixed up and RelocInfo iteration fixes up all references embedded in the generated code. This adds support for this mechanism to the builtins constants table builder. CodeObject() is now a new handle pointing to a dedicated self-reference marker in order to distinguish between self-references and references to undefined. In Factory::NewCode, we patch up the constants table. Bug: v8:6666 Change-Id: If74ed91bb1c3b8abb20ff2f0a87d1bcd9a1b0511 Reviewed-on: https://chromium-review.googlesource.com/1018468 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#52854}
-
- 22 Mar, 2018 1 commit
-
-
jgruber authored
This is a reland of 9afde91b Original change's description: > [builtins] Load external references from the external-reference-table > > Off-heap code cannot embed external references. With this CL, we load > from the external reference table (reached through the root pointer) > instead. > > In a follow-up, the table could be stored within the isolate itself, > removing one more level of indirection. > > Bug: v8:6666 > Change-Id: I4c612ad3d4112ec03c3b389f5bfb9cdc3dc8a671 > Reviewed-on: https://chromium-review.googlesource.com/970468 > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#52073} TBR=mstarzinger@chromium.org Bug: v8:6666, v8:7580 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I30639fe17ea345119d38a176a29d521c4b1904cb Reviewed-on: https://chromium-review.googlesource.com/975241 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#52141}
-
- 21 Mar, 2018 2 commits
-
-
Jakob Gruber authored
This reverts commit f8184738. Reason for revert: arm is still unhappy https://build.chromium.org/p/client.v8.ports/builders/V8%20Arm%20GC%20Stress/builds/6633 Original change's description: > Reland "[builtins] Load external references from the external-reference-table" > > This is a reland of 9afde91b > > Original change's description: > > [builtins] Load external references from the external-reference-table > > > > Off-heap code cannot embed external references. With this CL, we load > > from the external reference table (reached through the root pointer) > > instead. > > > > In a follow-up, the table could be stored within the isolate itself, > > removing one more level of indirection. > > > > Bug: v8:6666 > > Change-Id: I4c612ad3d4112ec03c3b389f5bfb9cdc3dc8a671 > > Reviewed-on: https://chromium-review.googlesource.com/970468 > > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > > Reviewed-by: Yang Guo <yangguo@chromium.org> > > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#52073} > > TBR=mstarzinger@chromium.org > > Bug: v8:6666, v8:7580 > Change-Id: I163cfc15605c1183b79ead77df0e37d71d60b6f7 > Reviewed-on: https://chromium-review.googlesource.com/972821 > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#52118} TBR=yangguo@chromium.org,mstarzinger@chromium.org,jgruber@chromium.org Change-Id: I5bcd1a1c84c6e9a6a24364390c9359d43c77120d No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:6666, v8:7580 Reviewed-on: https://chromium-review.googlesource.com/973782Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#52121}
-
jgruber authored
This is a reland of 9afde91b Original change's description: > [builtins] Load external references from the external-reference-table > > Off-heap code cannot embed external references. With this CL, we load > from the external reference table (reached through the root pointer) > instead. > > In a follow-up, the table could be stored within the isolate itself, > removing one more level of indirection. > > Bug: v8:6666 > Change-Id: I4c612ad3d4112ec03c3b389f5bfb9cdc3dc8a671 > Reviewed-on: https://chromium-review.googlesource.com/970468 > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#52073} TBR=mstarzinger@chromium.org Bug: v8:6666, v8:7580 Change-Id: I163cfc15605c1183b79ead77df0e37d71d60b6f7 Reviewed-on: https://chromium-review.googlesource.com/972821 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#52118}
-
- 20 Mar, 2018 2 commits
-
-
Michael Achenbach authored
This reverts commit 9afde91b. Reason for revert: https://build.chromium.org/p/client.v8.ports/builders/V8%20Arm/builds/6616 Original change's description: > [builtins] Load external references from the external-reference-table > > Off-heap code cannot embed external references. With this CL, we load > from the external reference table (reached through the root pointer) > instead. > > In a follow-up, the table could be stored within the isolate itself, > removing one more level of indirection. > > Bug: v8:6666 > Change-Id: I4c612ad3d4112ec03c3b389f5bfb9cdc3dc8a671 > Reviewed-on: https://chromium-review.googlesource.com/970468 > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#52073} TBR=yangguo@chromium.org,mstarzinger@chromium.org,jgruber@chromium.org Change-Id: Iecc2a68e54339e153f1d1e882d8972d5c9cff442 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:6666 Reviewed-on: https://chromium-review.googlesource.com/971902Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#52083}
-
jgruber authored
Off-heap code cannot embed external references. With this CL, we load from the external reference table (reached through the root pointer) instead. In a follow-up, the table could be stored within the isolate itself, removing one more level of indirection. Bug: v8:6666 Change-Id: I4c612ad3d4112ec03c3b389f5bfb9cdc3dc8a671 Reviewed-on: https://chromium-review.googlesource.com/970468 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52073}
-
- 05 Mar, 2018 1 commit
-
-
jgruber authored
Since we currently only fill the constants table if we're serializing, we should only create & finalize the table in that case. Otherwise, leave it initialized to empty_fixed_array. Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng Bug: v8:6666 Change-Id: I6ecbfac9dc9a9dac7ff0f11331be09b1cbfb4c18 Reviewed-on: https://chromium-review.googlesource.com/948490Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#51727}
-
- 01 Mar, 2018 1 commit
-
-
jgruber authored
External references are process-specific and thus need to be accessed through an indirection (or reloc'd by the linker). This CL moves all used external references to the builtins constants table and rewrites accesses to load from there. In the future, this could be made more efficient by removing levels of indirection or using the native linker. Bug: v8:6666 Change-Id: I63491670549654edeb59c60bb833acfdc5a48495 Reviewed-on: https://chromium-review.googlesource.com/939783Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#51646}
-
- 23 Feb, 2018 1 commit
-
-
jgruber authored
During builtins generation, parts of the builtins table may be filled with placeholder code objects. This CL ensures that such placeholders are replaced by the real builtin object during finalization of the builtins constants table. Bug: v8:6666 Change-Id: I3a2635b29b37690fd7e950b9f38d500704671afb Reviewed-on: https://chromium-review.googlesource.com/934241Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#51498}
-
- 21 Feb, 2018 1 commit
-
-
jgruber authored
This is a step towards off-heap (and eventually isolate-independent) builtins. Off-heap code cannot use the standard CallStub/CallRuntime mechanisms, since they directly embed the callee code object pointer within the caller. There are two main issues with that: 1. the callee may be moved by GC, and 2. the pc-relative addressing we currently use breaks (i.e. ends up pointing to a random spot on the heap) when moving the caller off-heap. This CL addresses that by introducing a constants list stored on the roots array. Instead of embedding code targets, we now have the option of loading them from constants list. The code sequence is: REX.W movq rax,[r13+0x4a0] // Load the constants cache. REX.W movq rdx,[rax+0xf] // From there, load the code target. ... REX.W addq rdx,0x5f // Add instruction_start. call rdx There's no visible performance impact on the web tooling benchmark. This list will later be extended to also contain other constants such as Strings. Bug: v8:6666 Change-Id: Ifcf67d1f682804ba0b6d3d0383216e16575b6bf5 Reviewed-on: https://chromium-review.googlesource.com/923729 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#51434}
-