- 16 Jan, 2020 1 commit
-
-
Leszek Swirski authored
Add support for internalizing an AstValueFactory using the off-thread factory. Includes adding ConsString support to OffThreadFactory. This introduces a Handle union wrapper, which is used in locations that can store a Handle or an OffThreadHandle. This is used in this patch for the internalized "string" field of AST strings, and will be able to be used for other similar fields in other classes (e.g. the ScopeInfo handle in Scope, object boilerplate descriptor handles, the inferred name handle on FunctionLiterals, etc.). It has a Factory-templated getter which returns the appropriate handle for the factory, and a debug-only tag to make sure the right getter is used at runtime. This union wrapper currently decomposes implicitly to a Handle if the getter is not called, to minimise code changes, but this implicit conversion will likely be removed for clarity. Bug: chromium:1011762 Change-Id: I5dd3a7bbdc483b66f5ff687e0079c545b636dc13 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993971 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#65816}
-
- 15 Jan, 2020 1 commit
-
-
Leszek Swirski authored
Introduce OffThreadFactory with initial string construction support. The OffThreadFactory shares with Factory a new CRTP base class, called FactoryBase. Methods in FactoryBase return a FactoryHandle<Factory, T> alias, which is Handle<T> for normal Factory and a new OffThreadHandle<T> for OffThreadFactory. OffThreadHandle<T> behaves like Handle<T>, except it stores the object in-line rather than needing external storage. Any shared factory methods are moved into FactoryBase, which uses CRTP to call the sub-class's AllocateRaw method (plus a few more customization points which need Isolate access on the main thread). Methods that used to take an Isolate or Factory, and are needed off the main thread, are now expected to be templated on the factory type and to use the appropriate handle. Once an OffThreadFactory has finished being used (e.g. off-thread compilation completed) its pages are "Published" into the main-thread Heap. To deal with string internalization without creating a bunch of ThinStrings, this is done in two stages: 1. 'FinishOffThread': The off-thread pages are walked to collect all slots pointing to "internalized" strings. After this is called it is invalid to allocate any more objects with the factory. 2. 'Publish': On the main thread, we transform these slots into <Handle to holder, offset> pairs, then for each saved slot re-internalize its string and update the slot to point to the internalized string. Bug: chromium:1011762 Change-Id: I008a694da3c357de34362bd86fe7e1f46b535d5e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1992434 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#65787}
-
- 08 Jul, 2019 1 commit
-
-
Peter Marshall authored
The client API provides a much simpler interface so that we don't have to deal with producers, consumers etc. directly. This CL removes all the code that dealt with the more complex API used previously. The architecture used here requires that the embedder call into Tracing::Initialize() to set up the tracing backend. The tracing controller then connects to this backend when calling DataSource::Register() and Tracing::NewTrace(). This will ultimately avoid the need for a virtual call (or two) for every trace event that need to be dispatched over the API - chrome can provide a backend and V8 will connect to it opaquely with the same code when tracing is enabled. Cq-Include-Trybots: luci.v8.try:v8_linux64_perfetto_dbg_ng Bug: v8:8339 Change-Id: I6b74fbb49ffcc89638caeb59ed3d5cc81238f3e8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1634916Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#62568}
-
- 18 Jun, 2019 1 commit
-
-
Jakob Gruber authored
This CL renames jsregexp.{h,cc} to regexp.{h,cc}, hides all non-public functions of RegExpImpl in the .cc file, and renames the public parts of RegExpImpl to just RegExp. Include directives from outside the src/regexp directory are limited to regexp.h, regexp-stack.h, and regexp-utils.h. We also expose all result codes that can be returned by irregexp code (including RETRY) on the public header since they are needed elsewhere, e.g. in builtins. Bug: v8:9359 Change-Id: Iae1a01ac9f6e1e4dc168f3fbe8fe8679cb6b1259 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1662297Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#62240}
-
- 06 Jun, 2019 1 commit
-
-
Igor Sheludko authored
The implementation is already quite trivial and in addition in case of ptr-compr this implementation becomes even simpler and C++ compiler gets the opportunity to hoist common computation of isolate root. Tbr: yangguo@chromium.org Bug: v8:7464, v8:7703 Change-Id: I6e59cd43253c9ade5a0e27025ea7fabecd5b7af7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1647171 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#62024}
-
- 02 May, 2019 1 commit
-
-
Maciej Goszczycki authored
Code relocation info is now always allocated in old-space. Before relocation info allocated for placeholders and builtins (which get replaced with trampolines in nosnap builds) would become unreachable. Since read-only space is not GCed and ReadOnlyHeapIterator doesn't check for reachability, ValidateSnapshot would fail finding unreachable objects returned by ReadOnlyHeapIterator. Because trampoline relocation info gets replaced with canonical one, this only affects no-embdded-builtins nosnap builds, which don't get much benefit from read-only relocation info anyway. A new check has been added to the read-only deserializer to verify that every read-only object is reachable at mksnapshot-time. The CombinedHeapIterator iteration order was changed to iterate over read-only space first, because that's how HeapIterator worked. This is a reland of 3d1d8eae Original change's description: > [heap] Skip ro-space from heap iterators, add CombinedHeapIterator. > > Read-only space sharing requires an iterator independent of heap. This > also enables future removal of read-only space from heap. > > Bug: v8:7464 > Change-Id: Ia07a9369494ea2c547d12c01ffa1d7b8b6bbeabc > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1552795 > Commit-Queue: Maciej Goszczycki <goszczycki@google.com> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Dan Elphick <delphick@chromium.org> > Cr-Commit-Position: refs/heads/master@{#60819} Bug: v8:7464 Change-Id: I49ae070955b77956962334a84f762ab29052d5ff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1566513Reviewed-by: Dan Elphick <delphick@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Maciej Goszczycki <goszczycki@google.com> Cr-Commit-Position: refs/heads/master@{#61185}
-
- 12 Apr, 2019 2 commits
-
-
Clemens Hammacher authored
This reverts commit 3d1d8eae. Reason for revert: Speculative revert; seems to break all nosnap bots, e.g. https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20nosnap/25240 Original change's description: > [heap] Skip ro-space from heap iterators, add CombinedHeapIterator. > > Read-only space sharing requires an iterator independent of heap. This > also enables future removal of read-only space from heap. > > Bug: v8:7464 > Change-Id: Ia07a9369494ea2c547d12c01ffa1d7b8b6bbeabc > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1552795 > Commit-Queue: Maciej Goszczycki <goszczycki@google.com> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Dan Elphick <delphick@chromium.org> > Cr-Commit-Position: refs/heads/master@{#60819} TBR=ulan@chromium.org,hpayer@chromium.org,delphick@chromium.org,goszczycki@google.com Change-Id: I64b58b1b0c5eb073a6d2cfae81bb4de65f0511bf No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7464 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1565895Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#60825}
-
Maciej Goszczycki authored
Read-only space sharing requires an iterator independent of heap. This also enables future removal of read-only space from heap. Bug: v8:7464 Change-Id: Ia07a9369494ea2c547d12c01ffa1d7b8b6bbeabc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1552795 Commit-Queue: Maciej Goszczycki <goszczycki@google.com> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#60819}
-
- 28 Feb, 2019 1 commit
-
-
Maciej Goszczycki authored
This provides a single point where read-only space sharing will be controlled. Eventually ReadOnlyDeserializer will take ReadOnlyHeap instead of Isolate, first steps include https://chromium-review.googlesource.com/c/v8/v8/+/1483054 Bug: v8:7464 Change-Id: I213819aeca6fca335235025c9195edf474230eda Reviewed-on: https://chromium-review.googlesource.com/c/1489087 Commit-Queue: Maciej Goszczycki <goszczycki@google.com> Reviewed-by: Dan Elphick <delphick@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#59954}
-
- 29 Jan, 2019 1 commit
-
-
Michael Lippautz authored
TracedGlobal integrates with the use case of EmbedderHeapTracer and replaces regular weak Global or Persistent nodes for such cases. This allows to simplify the case for regular weak handles in a sense that they follow regular weak semantics (if the underlying object is otherwise unreachable the weak handle will be reset). TracedGlobal requires slightly different semantics in the sense that it can be required to keep them alive on Scavenge garbage collections because there's a transitive path that is only known when using the EmbedderHeapTracer. TracedGlobal accomodates that use case. TracedGlobal follows move semantics and can thus be used in regular std containers without wrapping data structure. The internal state uses 20% less memory and allows for only iterating those nodes when necessary. The design trades the virtual call when iterating interesting persistents in the GC prologue with calling out through the EmbedderHeapTracer for each node which is also a virtual call. There is one less iteration over the set of handles required though and the design is robust against recursive GCs that mutate the embedder state during the prologue callback. Bug: chromium:923361 Change-Id: Idbacfbe4723cd12af9de21058a4792e51dc4df74 Reviewed-on: https://chromium-review.googlesource.com/c/1425523 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#59183}
-
- 30 Oct, 2018 1 commit
-
-
Andreas Haas authored
This is the V8 side of the implementation. You can take a look at a prototype of the Chrome side changes in https://crrev.com/c/1273043. Chrome could also use V8's default implementation of the trap handler, see https://crrev.com/c/1290952. Bug: v8:6743 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I9bb3e717db17a4f30bbb8acfd80a1f6510d463ff Reviewed-on: https://chromium-review.googlesource.com/c/1283111 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#57117}
-
- 26 Oct, 2018 1 commit
-
-
Andreas Haas authored
This CL refactors the existing trap handler code for Linux to allow a cleaner extension to Windows. 1) The CL extracts platform-specific code into separate files, see https://docs.google.com/document/d/1HCgKIpdjy_CEodTLvZ5VuykDI6gGTHrTtau2j0zwm28. Specifically this means: * Move posix-specific API functions from v8.h to v8-wasm-trap-handler-posix.h. Deprecate the existing TryHandleSignal API function. * Move posix-specific function declarations from trap-handler-internal.h to handler-inside-posix.h * Move posix-specific function definitions from handler-shared.cc to handler-outside-posix.cc 2) The CL changes filenames from *-linux.* to *-posix.*. I expect that most of the implementation for MacOS will be the same as for Linux. Bug: v8:6743 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I4bb7f199564a2f01042084d15a82311d11a93c7b Reviewed-on: https://chromium-review.googlesource.com/c/1280324 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by: Ben Titzer <titzer@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#57028}
-
- 21 Sep, 2018 1 commit
-
-
Marja Hölttä authored
Also fixing DEPS include rules for heap-write-barrier.h BUG=v8:5402,v8:8015 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ia785da321bc6c6f4c375ae8c866a0bf294e64f5b Reviewed-on: https://chromium-review.googlesource.com/1238453Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#56138}
-
- 10 Sep, 2018 1 commit
-
-
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: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#55757}
-
- 24 Aug, 2018 1 commit
-
-
Dan Elphick authored
This doubles the size of the snapshot since it creates all of the handlers twice (and it doesn't use any of these new ones). However it's all behind a flag. For now all bytecode handlers are marked as being not Isolate independent to prevent snapshot creation failures. Bug: v8:8068 Change-Id: Id49f521445643d9fc6b141353f0a29b585160e10 Reviewed-on: https://chromium-review.googlesource.com/1185100 Commit-Queue: Dan Elphick <delphick@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#55411}
-
- 27 Jul, 2018 1 commit
-
-
Michael Lippautz authored
The initial CL only re-wired the macro but did not convert the remaining manual uses. Change-Id: Ia4c6dea006d7c026d2376affee0b7027f5aa7895 Reviewed-on: https://chromium-review.googlesource.com/1152907Reviewed-by: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#54753}
-
- 08 May, 2018 1 commit
-
-
Tobias Tebbi authored
Change-Id: Ibb6e10caaa4fcdb29c35baef71cf1b4faef45bc4 Reviewed-on: https://chromium-review.googlesource.com/1042389Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53069}
-
- 09 Apr, 2018 1 commit
-
-
Jakob Kummerow authored
There is no good reason to have the meat of most objects' initialization logic in heap.cc, all wrapped by the CALL_HEAP_FUNCTION macro. Instead, this CL changes the protocol between Heap and Factory to be AllocateRaw, and all object initialization work after (possibly retried) successful raw allocation happens in the Factory. This saves about 20KB of binary size on x64. Original review: https://chromium-review.googlesource.com/c/v8/v8/+/959533 Originally landed as r52416 / f9a2e24b Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Id072cbe6b3ed30afd339c7e502844b99ca12a647 Reviewed-on: https://chromium-review.googlesource.com/1000540 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52492}
-
- 06 Apr, 2018 2 commits
-
-
Michael Achenbach authored
This reverts commit f9a2e24b. Reason for revert: gc stress failures not all fixed by follow up. Original change's description: > [cleanup] Refactor the Factory > > There is no good reason to have the meat of most objects' initialization > logic in heap.cc, all wrapped by the CALL_HEAP_FUNCTION macro. Instead, > this CL changes the protocol between Heap and Factory to be AllocateRaw, > and all object initialization work after (possibly retried) successful > raw allocation happens in the Factory. > > This saves about 20KB of binary size on x64. > > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng > Change-Id: Icbfdc4266d7be8b48d2fe085f03411743dc6a0ca > Reviewed-on: https://chromium-review.googlesource.com/959533 > Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Hannes Payer <hpayer@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Cr-Commit-Position: refs/heads/master@{#52416} TBR=jkummerow@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,hpayer@chromium.org Change-Id: Idbbc53478742f3e9525eee83342afc6aedae122f No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/999414Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#52420}
-
Jakob Kummerow authored
There is no good reason to have the meat of most objects' initialization logic in heap.cc, all wrapped by the CALL_HEAP_FUNCTION macro. Instead, this CL changes the protocol between Heap and Factory to be AllocateRaw, and all object initialization work after (possibly retried) successful raw allocation happens in the Factory. This saves about 20KB of binary size on x64. Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Icbfdc4266d7be8b48d2fe085f03411743dc6a0ca Reviewed-on: https://chromium-review.googlesource.com/959533 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#52416}
-
- 05 May, 2017 1 commit
-
-
Michael Starzinger authored
This makes sure that only the "asm-js.h" header is exposed to outside the directory holding the asm.js validator. It ensures that internals don't leak out of that component, unless they are explicitly exposed through the defined interface. R=clemensh@chromium.org BUG=v8:6127 Change-Id: I7c41782254cfce102af8edf4356205cfca904e60 Reviewed-on: https://chromium-review.googlesource.com/496147Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#45125}
-
- 07 Apr, 2017 1 commit
-
-
jkummerow authored
and out of the main library. This saves about 5% of binary size (800KB on x64, 373KB on android_arm). Only the GN build is supported; the GYP build is maintained working but does not support the feature. Previously landed as 4782bc0d / r44412. BUG=v8:6055 CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_linux_nosnap_rel; Review-Url: https://codereview.chromium.org/2760233005 Cr-Commit-Position: refs/heads/master@{#44489}
-
- 05 Apr, 2017 2 commits
-
-
kozyatinskiy authored
Revert of [snapshot] Move builtins generation into mksnapshot (patchset #8 id:160001 of https://codereview.chromium.org/2760233005/ ) Reason for revert: I think that this CL breaks chromium compilation on windows with clang (). All other CLs in the list looks trivial and don't change test/unittest/BUILD.gn. [42456/47924] CXX obj/v8/test/unittests/unittests/value-serializer-unittest.obj [42457/47924] LINK unittests.exe unittests.exe.pdb FAILED: unittests.exe unittests.exe.pdb E:/b/depot_tools/python276_bin/python.exe ../../build/toolchain/win/tool_wrapper.py link-wrapper environment.x64 False link.exe /nologo /OUT:./unittests.exe /PDB:./unittests.exe.pdb @./unittests.exe.rsp bitmap-unittest.obj : error LNK2019: unresolved external symbol "public: void __cdecl v8::internal::List<class v8::internal::AllocationObserver *,class v8::internal::FreeStoreAllocationPolicy>::Add(class v8::internal::AllocationObserver * const &,class v8::internal::FreeStoreAllocationPolicy)" (?Add@?$List@PEAVAllocationObserver@internal@v8@@VFreeStoreAllocationPolicy@23@@internal@v8@@QEAAXAEBQEAVAllocationObserver@23@VFreeStoreAllocationPolicy@23@@Z) referenced in function "public: virtual void __cdecl v8::internal::Space::AddAllocationObserver(class v8::internal::AllocationObserver *)" (?AddAllocationObserver@Space@internal@v8@@UEAAXPEAVAllocationObserver@23@@Z) slot-set-unittest.obj : error LNK2001: unresolved external symbol "public: void __cdecl v8::internal::List<class v8::internal::AllocationObserver *,class v8::internal::FreeStoreAllocationPolicy>::Add(class v8::internal::AllocationObserver * const &,class v8::internal::FreeStoreAllocationPolicy)" (?Add@?$List@PEAVAllocationObserver@internal@v8@@VFreeStoreAllocationPolicy@23@@internal@v8@@QEAAXAEBQEAVAllocationObserver@23@VFreeStoreAllocationPolicy@23@@Z) bitmap-unittest.obj : error LNK2019: unresolved external symbol "public: bool __cdecl v8::internal::List<class v8::internal::AllocationObserver *,class v8::internal::FreeStoreAllocationPolicy>::RemoveElement(class v8::internal::AllocationObserver * const &)" (?RemoveElement@?$List@PEAVAllocationObserver@internal@v8@@VFreeStoreAllocationPolicy@23@@internal@v8@@QEAA_NAEBQEAVAllocationObserver@23@@Z) referenced in function "public: virtual void __cdecl v8::internal::Space::RemoveAllocationObserver(class v8::internal::AllocationObserver *)" (?RemoveAllocationObserver@Space@internal@v8@@UEAAXPEAVAllocationObserver@23@@Z) slot-set-unittest.obj : error LNK2001: unresolved external symbol "public: bool __cdecl v8::internal::List<class v8::internal::AllocationObserver *,class v8::internal::FreeStoreAllocationPolicy>::RemoveElement(class v8::internal::AllocationObserver * const &)" (?RemoveElement@?$List@PEAVAllocationObserver@internal@v8@@VFreeStoreAllocationPolicy@23@@internal@v8@@QEAA_NAEBQEAVAllocationObserver@23@@Z) ./unittests.exe : fatal error LNK1120: 2 unresolved externals Original issue's description: > [snapshot] Move builtins generation into mksnapshot > > and out of the main library. This saves about 5% of binary size > (800KB on x64, 373KB on android_arm). > > Only the GN build is supported; the GYP build is maintained working > but does not support the feature. > > BUG=v8:6055 > CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_linux_nosnap_rel; > > Review-Url: https://codereview.chromium.org/2760233005 > Cr-Commit-Position: refs/heads/master@{#44412} > Committed: https://chromium.googlesource.com/v8/v8/+/4782bc0df89ceb127e38017b8dcf531222a0e966 TBR=jgruber@chromium.org,rmcilroy@chromium.org,machenbach@chromium.org,jkummerow@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:6055 Review-Url: https://codereview.chromium.org/2803903002 Cr-Commit-Position: refs/heads/master@{#44422}
-
jkummerow authored
and out of the main library. This saves about 5% of binary size (800KB on x64, 373KB on android_arm). Only the GN build is supported; the GYP build is maintained working but does not support the feature. BUG=v8:6055 CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_linux_nosnap_rel; Review-Url: https://codereview.chromium.org/2760233005 Cr-Commit-Position: refs/heads/master@{#44412}
-
- 13 Mar, 2017 3 commits
-
-
eholk authored
This is basically the minimum viable signal handler for Wasm bounds checks. It includes the TLS check and the fine grained instructions checks. These two checks provide most of the safety for the signal handler. Future CLs will add code range and data range checks for more robustness. The trap handling code and data structures are all in src/trap-handler, with the code that actually runs in the signal handler confined to src/trap-handler/signal-handler.cc. This changes adds a new V8 API that the embedder should call from a signal handler that will give V8 the chance to handle the fault first. For hosts that do not want to implement their own signal handler, we include the option to install a simple one. This simple handler is also used for the tests. When a Wasm module is instantiated, information about each function is passed to the trap handler, which is used to classify faults. These are removed during the instance finalizer. Several future enhancements are planned before turning this on by default. Obviously, the additional checks will be added to MaybeHandleFault. We are also planning to add a two-level CodeObjectData table that is grouped by isolates to make cleanup easier and also reduce potential for contending on a single data structure. BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277 Review-Url: https://codereview.chromium.org/2371833007 Cr-Original-Original-Commit-Position: refs/heads/master@{#43523} Committed: https://chromium.googlesource.com/v8/v8/+/a5af7fe9ee388a636675f4a6872b1d34fa7d1a7a Review-Url: https://codereview.chromium.org/2371833007 Cr-Original-Commit-Position: refs/heads/master@{#43755} Committed: https://chromium.googlesource.com/v8/v8/+/338622d7cae787a63cece1f2e79a8b030023940b Review-Url: https://codereview.chromium.org/2371833007 Cr-Commit-Position: refs/heads/master@{#43759}
-
eholk authored
Revert of [wasm] Initial signal handler (patchset #60 id:1170001 of https://codereview.chromium.org/2371833007/ ) Reason for revert: ASAN breakage, such as https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20ASAN/builds/19111/steps/Check/logs/grow-memory Original issue's description: > [wasm] Initial signal handler > > This is basically the minimum viable signal handler for Wasm bounds checks. > It includes the TLS check and the fine grained instructions checks. These > two checks provide most of the safety for the signal handler. Future CLs will > add code range and data range checks for more robustness. > > The trap handling code and data structures are all in src/trap-handler, with > the code that actually runs in the signal handler confined to > src/trap-handler/signal-handler.cc. > > This changes adds a new V8 API that the embedder should call from a signal > handler that will give V8 the chance to handle the fault first. For hosts that > do not want to implement their own signal handler, we include the option to > install a simple one. This simple handler is also used for the tests. > > When a Wasm module is instantiated, information about each function is passed > to the trap handler, which is used to classify faults. These are removed during > the instance finalizer. > > Several future enhancements are planned before turning this on by default. > Obviously, the additional checks will be added to MaybeHandleFault. We are > also planning to add a two-level CodeObjectData table that is grouped by > isolates to make cleanup easier and also reduce potential for contending on > a single data structure. > > BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277 > > Review-Url: https://codereview.chromium.org/2371833007 > Cr-Original-Commit-Position: refs/heads/master@{#43523} > Committed: https://chromium.googlesource.com/v8/v8/+/a5af7fe9ee388a636675f4a6872b1d34fa7d1a7a > Review-Url: https://codereview.chromium.org/2371833007 > Cr-Commit-Position: refs/heads/master@{#43755} > Committed: https://chromium.googlesource.com/v8/v8/+/338622d7cae787a63cece1f2e79a8b030023940b TBR=ahaas@chromium.org,bradnelson@google.com,hpayer@chromium.org,jochen@chromium.org,mark@chromium.org,mseaborn@chromium.org,titzer@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277 Review-Url: https://codereview.chromium.org/2744383002 Cr-Commit-Position: refs/heads/master@{#43757}
-
eholk authored
This is basically the minimum viable signal handler for Wasm bounds checks. It includes the TLS check and the fine grained instructions checks. These two checks provide most of the safety for the signal handler. Future CLs will add code range and data range checks for more robustness. The trap handling code and data structures are all in src/trap-handler, with the code that actually runs in the signal handler confined to src/trap-handler/signal-handler.cc. This changes adds a new V8 API that the embedder should call from a signal handler that will give V8 the chance to handle the fault first. For hosts that do not want to implement their own signal handler, we include the option to install a simple one. This simple handler is also used for the tests. When a Wasm module is instantiated, information about each function is passed to the trap handler, which is used to classify faults. These are removed during the instance finalizer. Several future enhancements are planned before turning this on by default. Obviously, the additional checks will be added to MaybeHandleFault. We are also planning to add a two-level CodeObjectData table that is grouped by isolates to make cleanup easier and also reduce potential for contending on a single data structure. BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277 Review-Url: https://codereview.chromium.org/2371833007 Cr-Original-Commit-Position: refs/heads/master@{#43523} Committed: https://chromium.googlesource.com/v8/v8/+/a5af7fe9ee388a636675f4a6872b1d34fa7d1a7a Review-Url: https://codereview.chromium.org/2371833007 Cr-Commit-Position: refs/heads/master@{#43755}
-
- 01 Mar, 2017 2 commits
-
-
bmeurer authored
Revert of [wasm] Initial signal handler (patchset #56 id:1090001 of https://codereview.chromium.org/2371833007/ ) Reason for revert: Breaks tree, i.e. https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20ASAN/builds/18928/steps/Check/logs/grow-memory Original issue's description: > [wasm] Initial signal handler > > This is basically the minimum viable signal handler for Wasm bounds checks. > It includes the TLS check and the fine grained instructions checks. These > two checks provide most of the safety for the signal handler. Future CLs will > add code range and data range checks for more robustness. > > The trap handling code and data structures are all in src/trap-handler, with > the code that actually runs in the signal handler confined to > src/trap-handler/signal-handler.cc. > > This changes adds a new V8 API that the embedder should call from a signal > handler that will give V8 the chance to handle the fault first. For hosts that > do not want to implement their own signal handler, we include the option to > install a simple one. This simple handler is also used for the tests. > > When a Wasm module is instantiated, information about each function is passed > to the trap handler, which is used to classify faults. These are removed during > the instance finalizer. > > Several future enhancements are planned before turning this on by default. > Obviously, the additional checks will be added to MaybeHandleFault. We are > also planning to add a two-level CodeObjectData table that is grouped by > isolates to make cleanup easier and also reduce potential for contending on > a single data structure. > > BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277 > > Review-Url: https://codereview.chromium.org/2371833007 > Cr-Commit-Position: refs/heads/master@{#43523} > Committed: https://chromium.googlesource.com/v8/v8/+/a5af7fe9ee388a636675f4a6872b1d34fa7d1a7a TBR=ahaas@chromium.org,bradnelson@google.com,hpayer@chromium.org,jochen@chromium.org,mark@chromium.org,mseaborn@chromium.org,titzer@chromium.org,eholk@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277 Review-Url: https://codereview.chromium.org/2723133003 Cr-Commit-Position: refs/heads/master@{#43525}
-
eholk authored
This is basically the minimum viable signal handler for Wasm bounds checks. It includes the TLS check and the fine grained instructions checks. These two checks provide most of the safety for the signal handler. Future CLs will add code range and data range checks for more robustness. The trap handling code and data structures are all in src/trap-handler, with the code that actually runs in the signal handler confined to src/trap-handler/signal-handler.cc. This changes adds a new V8 API that the embedder should call from a signal handler that will give V8 the chance to handle the fault first. For hosts that do not want to implement their own signal handler, we include the option to install a simple one. This simple handler is also used for the tests. When a Wasm module is instantiated, information about each function is passed to the trap handler, which is used to classify faults. These are removed during the instance finalizer. Several future enhancements are planned before turning this on by default. Obviously, the additional checks will be added to MaybeHandleFault. We are also planning to add a two-level CodeObjectData table that is grouped by isolates to make cleanup easier and also reduce potential for contending on a single data structure. BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277 Review-Url: https://codereview.chromium.org/2371833007 Cr-Commit-Position: refs/heads/master@{#43523}
-
- 05 Dec, 2016 1 commit
-
-
leszeks authored
This allows us to optimise the bytecode liveness analysis to jump directly to previously seen indices. The analysis is optimised to store a stack of loop ends (JumpLoop bytecode indices), and iterate through these indices directly rather than looping through the bytecode array to find them. Review-Url: https://codereview.chromium.org/2536653003 Cr-Commit-Position: refs/heads/master@{#41485}
-
- 29 Nov, 2016 3 commits
-
-
leszeks authored
Replaces the graph-based liveness analyzer in the bytecode graph builder with an initial bytecode-based liveness analysis pass, which is added to the existing loop extent analysis. Now the StateValues in the graph have their inputs initialised to optimized_out, rather than being modified after the graph is built. Review-Url: https://codereview.chromium.org/2523893003 Cr-Commit-Position: refs/heads/master@{#41355}
-
leszeks authored
Revert of [ignition/turbo] Perform liveness analysis on the bytecodes (patchset #17 id:320001 of https://codereview.chromium.org/2523893003/ ) Reason for revert: Breaks the build: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20shared/builds/14886 Original issue's description: > [ignition/turbo] Perform liveness analysis on the bytecodes > > Replaces the graph-based liveness analyzer in the bytecode graph builder > with an initial bytecode-based liveness analysis pass, which is added to > the existing loop extent analysis. > > Now the StateValues in the graph have their inputs initialised to > optimized_out, rather than being modified after the graph is built. > > Committed: https://crrev.com/1852300954c216c29cf93444430681d213e87925 > Cr-Commit-Position: refs/heads/master@{#41344} TBR=jarin@chromium.org,rmcilroy@chromium.org,yangguo@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review-Url: https://codereview.chromium.org/2541443002 Cr-Commit-Position: refs/heads/master@{#41346}
-
leszeks authored
Replaces the graph-based liveness analyzer in the bytecode graph builder with an initial bytecode-based liveness analysis pass, which is added to the existing loop extent analysis. Now the StateValues in the graph have their inputs initialised to optimized_out, rather than being modified after the graph is built. Review-Url: https://codereview.chromium.org/2523893003 Cr-Commit-Position: refs/heads/master@{#41344}
-
- 22 Nov, 2016 1 commit
-
-
leszeks authored
Now that we have a JumpLoop bytecode, we can heavily simplify the branch/loop analysis by assuming that only JumpLoop bytecodes are backwards edges, and performing the loop analysis as a single (backwards) pass. This allows us to get rid of the branch analysis entirely, and builds a framework to do liveness analysis in the same pass. Review-Url: https://codereview.chromium.org/2519983002 Cr-Commit-Position: refs/heads/master@{#41194}
-
- 12 Oct, 2016 1 commit
-
-
alph authored
Review-Url: https://codereview.chromium.org/2404663002 Cr-Commit-Position: refs/heads/master@{#40237}
-
- 03 Aug, 2016 1 commit
-
-
jochen authored
This will allow for the background parser to parse inner functions BUG=v8:5215 R=marja@chromium.org,verwaest@chromium.org Review-Url: https://codereview.chromium.org/2198043002 Cr-Commit-Position: refs/heads/master@{#38291}
-
- 27 Jul, 2016 1 commit
-
-
fmeawad authored
V8 has had a trace event macro interface for while, but without a tracing controller a standalone V8 would be unable to collect traces. This CL introduces a complete Tracing Controller system for V8. It is fully function except that it does not yet store trace event args. This CL has a few components, The tracing controller itself, contributed by the author of this CL The Trace config (including the parser), contributed by lpy@ The Trace Object, Trace Writer, and Trace Buffer are all contributed by rksang@ BUG=v8:4561 LOG=N The original CL was failing the V8 Arm Builder: https://build.chromium.org/p/client.v8.ports/builders/V8%20Arm%20-%20builder/builds/2456 and the V8 Mips Builder: https://build.chromium.org/p/client.v8.ports/builders/V8%20Mips%20-%20builder/builds/2506 The failure is due to undefined behavior of CHECK_EQ of 2 const char* Fix in patch #1 Committed: https://crrev.com/3d598452679ce208ad9b2f48e0fb3fae352ce375 Cr-Commit-Position: refs/heads/master@{#38073} patch from issue 2137013006 at patchset 200001 (http://crrev.com/2137013006#ps200001) Review-Url: https://codereview.chromium.org/2183923004 Cr-Commit-Position: refs/heads/master@{#38104}
-
- 26 Jul, 2016 2 commits
-
-
lpy authored
Revert of [Tracing] V8 Tracing Controller (patchset #11 id:200001 of https://codereview.chromium.org/2137013006/ ) Reason for revert: Revert this CL due to V8 Arm Builder failure and V8 Mips Builder failure. https://build.chromium.org/p/client.v8.ports/builders/V8%20Arm%20-%20builder/builds/2456 https://build.chromium.org/p/client.v8.ports/builders/V8%20Mips%20-%20builder/builds/2506 Original issue's description: > [Tracing] V8 Tracing Controller > > V8 has had a trace event macro interface for while, but without a tracing > controller a standalone V8 would be unable to collect traces. > > This CL introduces a complete Tracing Controller system for V8. > It is fully function except that it does not yet store trace event args. > > This CL has a few components, > The tracing controller itself, contributed by the author of this CL > The Trace config (including the parser), contributed by lpy@ > The Trace Object, Trace Writer, and Trace Buffer are all contributed by rksang@ > > BUG=v8:4561 > LOG=N > > Committed: https://crrev.com/3d598452679ce208ad9b2f48e0fb3fae352ce375 > Cr-Commit-Position: refs/heads/master@{#38073} TBR=jochen@chromium.org,mattloring@google.com,rskang@google.com,yangguo@chromium.org,fmeawad@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4561 Review-Url: https://codereview.chromium.org/2183943002 Cr-Commit-Position: refs/heads/master@{#38074}
-
fmeawad authored
V8 has had a trace event macro interface for while, but without a tracing controller a standalone V8 would be unable to collect traces. This CL introduces a complete Tracing Controller system for V8. It is fully function except that it does not yet store trace event args. This CL has a few components, The tracing controller itself, contributed by the author of this CL The Trace config (including the parser), contributed by lpy@ The Trace Object, Trace Writer, and Trace Buffer are all contributed by rksang@ BUG=v8:4561 LOG=N Review-Url: https://codereview.chromium.org/2137013006 Cr-Commit-Position: refs/heads/master@{#38073}
-
- 15 Jul, 2016 1 commit
-
-
oth authored
> Original issue's description: > [interpreter] Reduce dependencies in bytecodes.{h,cc} > > This CL reduces the number of dependencies bytecodes.{h,cc} to facilitate > generating the bytecode peephole optimizer table during build. Specifically, > it avoids depending on v8_base. > > BUG=v8:4280 > LOG=N > > Committed: https://crrev.com/4edebb1cd870ae6c1359ad54f83e618e185883b1 > Cr-Commit-Position: refs/heads/master@{#37715} BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/2149093002 Cr-Commit-Position: refs/heads/master@{#37794}
-