AuroraMiddleware/v8
1
0
Fork 0
Code Issues 2 Pull Requests Releases Wiki Activity
c75b543ddb
v8/src/DEPS

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

55 lines
1.6 KiB
Plaintext
Raw Normal View History

Add DEPS files and run checkdeps in presubmit check BUG=none R=jkummerow@chromium.org LOG=n Review URL: https://codereview.chromium.org/312763002 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21642 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-06-03 13:39:42 +00:00
include_rules = [
Implement tracing interface for v8 This is based on the Skia Implementation. More on the project can be found here: https://docs.google.com/a/chromium.org/document/d/1_4LAnInOB8tM_DLjptWiszRwa4qwiSsDzMkO4tU-Qes/edit#heading=h.p97rw6yt8o2j The V8 Tracing platform will replace the isolate->event_logger(). But since the current embedders (namely chromium) currently use the isolate->event_logger, I made the default implementation (event-tracer) call into isolate->event_logger if an event_logger was set. Once the embedders properly implement the interface (for example in chromium it would look like this: https://codereview.chromium.org/707273005/), the default implementation will be doing nothing. Once the embedders side is fixed, we will change how V8 uses the tracing framework beyond the call from Logger:CallEventLogger. (which would also include a d8 implementation) BUG=v8:4560 LOG=N Review URL: https://codereview.chromium.org/988893003 Cr-Commit-Position: refs/heads/master@{#32959}
2015-12-17 18:48:07 +00:00
"+base/trace_event/common/trace_event_common.h",
Add DEPS files and run checkdeps in presubmit check BUG=none R=jkummerow@chromium.org LOG=n Review URL: https://codereview.chromium.org/312763002 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21642 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-06-03 13:39:42 +00:00
"+src",
[asm.js] Ensure proper encapsulation of "asmjs" component. 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/496147 Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#45125}
2017-05-04 13:52:39 +00:00
"-src/asmjs",
"+src/asmjs/asm-js.h",
Prevent direct inclusion of headers from TF. R=jochen@chromium.org, titzer@chromium.org Review URL: https://codereview.chromium.org/438243004 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22874 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-08-05 13:20:26 +00:00
"-src/compiler",
"+src/compiler/pipeline.h",
Separate CodeAssembler and CodeStubAssembler This separation is needed to make two goals possible simultaneously: * is should be possible to offer V8 components a simple, clean interface to TurboFan's low-level code generation that doesn't expose details about the TF. * it should be possible to easily create new CodeAssembler "macros" that don't require a review from an OWNER of the compiler directory. Review URL: https://codereview.chromium.org/1875583003 Cr-Commit-Position: refs/heads/master@{#35576}
2016-04-18 11:57:06 +00:00
"+src/compiler/code-assembler.h",
Initial import of v8-native WASM. As discussed in person, this adds the code from v8-native-prototype into V8 proper, guarded by GYP flags that do not build the code by default. Passing wasm=on to 'make' or setting v8_wasm as a GYP flag activates building of this code. An additional header file is added to and exported from the compiler directory, src/compiler/wasm-compiler.h. This exposes a limited interface with opaque Node and Graph types to the decoder to build TF graphs, as well as functions to compile WASM graphs. The mjsunit tests added are blacklisted because they fail without the WASM object exposed to JS, which is also disabled by the build config option. This corresponds closely to https://github.com/WebAssembly/v8-native-prototype/commit/5981e06ebc9b1e578831d03100f17ebb77970ee0, with some formatting fixes and moving some files into src/compiler. R=mstarzinger@chromium.org, bradnelson@chromium.org BUG= Review URL: https://codereview.chromium.org/1504713014 Cr-Commit-Position: refs/heads/master@{#32794}
2015-12-11 12:26:16 +00:00
"+src/compiler/wasm-compiler.h",
[heap] Avoid overzealous inclusion of heap internal headers. This is a first step towards constraining down the heap interface to just the heap.h file. Note that many includes still leak through that file to the global "src" directory, but there now is a single place controlling which declarations leak that way. Especially inclusion of inline header files within "heap" has been limited drastically. R=hpayer@chromium.org,mlippautz@chromium.org Review URL: https://codereview.chromium.org/1281233003 Cr-Commit-Position: refs/heads/master@{#30092}
2015-08-10 16:32:08 +00:00
"-src/heap",
Reland "[heap] Skip ro-space from heap iterators, add CombinedHeapIterator." 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 3d1d8eae772877422e7082571e77c326e7e8e60a 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/+/1566513 Reviewed-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}
2019-05-02 15:35:51 +00:00
"+src/heap/combined-heap.h",
[api, global-handles] Add TracedGlobal 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}
2019-01-29 19:12:21 +00:00
"+src/heap/embedder-tracing.h",
Reland: [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. Original review: https://chromium-review.googlesource.com/c/v8/v8/+/959533 Originally landed as r52416 / f9a2e24bbc65c2dcb09a94ff62ad663cacef0f96 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}
2018-04-09 19:11:22 +00:00
"+src/heap/factory.h",
"+src/heap/factory-inl.h",
[heap] Avoid overzealous inclusion of heap internal headers. This is a first step towards constraining down the heap interface to just the heap.h file. Note that many includes still leak through that file to the global "src" directory, but there now is a single place controlling which declarations leak that way. Especially inclusion of inline header files within "heap" has been limited drastically. R=hpayer@chromium.org,mlippautz@chromium.org Review URL: https://codereview.chromium.org/1281233003 Cr-Commit-Position: refs/heads/master@{#30092}
2015-08-10 16:32:08 +00:00
"+src/heap/heap.h",
"+src/heap/heap-inl.h",
Update manual write barrier calls for new entry point 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/1152907 Reviewed-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}
2018-07-27 12:43:39 +00:00
"+src/heap/heap-write-barrier-inl.h",
[objects.h splitting] Move JSObject + subclasses 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/1238453 Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#56138}
2018-09-21 12:02:47 +00:00
"+src/heap/heap-write-barrier.h",
[roheap][ptr-compr] Move ReadOnlyHeap::GetReadOnlyRoots() to inl file 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}
2019-06-06 13:10:02 +00:00
"+src/heap/read-only-heap-inl.h",
[heap] Isolate read-only space creation 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}
2019-02-28 16:07:25 +00:00
"+src/heap/read-only-heap.h",
DevTools: Do not allow v8 to use inspector. Review-Url: https://codereview.chromium.org/2404663002 Cr-Commit-Position: refs/heads/master@{#40237}
2016-10-12 19:24:42 +00:00
"-src/inspector",
[interpreter] Add basic framework for bytecode handler code generation. Adds basic support for generation of interpreter bytecode handler code snippets. The InterpreterAssembler class exposes a set of low level, interpreter specific operations which can be used to build a Turbofan graph. The Interpreter class generates a bytecode handler snippet for each bytecode by assembling operations using an InterpreterAssembler. Currently only two simple bytecodes are supported: LoadLiteral0 and Return. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1239793002 Cr-Commit-Position: refs/heads/master@{#29814}
2015-07-23 14:21:26 +00:00
"-src/interpreter",
[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. Review-Url: https://codereview.chromium.org/2523893003 Cr-Commit-Position: refs/heads/master@{#41355}
2016-11-29 12:26:54 +00:00
"+src/interpreter/bytecode-array-accessor.h",
[Interpreter] Skeleton bytecode graph builder Add skeleton version bytecode-graph-builder.{h,cc} for existing bytecodes. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1291693004 Cr-Commit-Position: refs/heads/master@{#30687}
2015-09-10 16:21:34 +00:00
"+src/interpreter/bytecode-array-iterator.h",
[ignition] Rewrite reverse iterator as random iterator 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}
2016-12-05 13:03:07 +00:00
"+src/interpreter/bytecode-array-random-iterator.h",
Reland "[interpreter] Reduce dependencies in bytecodes.{h,cc}" > 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}
2016-07-15 12:03:04 +00:00
"+src/interpreter/bytecode-decoder.h",
"+src/interpreter/bytecode-flags.h",
"+src/interpreter/bytecode-register.h",
[interpreter] Add basic framework for bytecode handler code generation. Adds basic support for generation of interpreter bytecode handler code snippets. The InterpreterAssembler class exposes a set of low level, interpreter specific operations which can be used to build a Turbofan graph. The Interpreter class generates a bytecode handler snippet for each bytecode by assembling operations using an InterpreterAssembler. Currently only two simple bytecodes are supported: LoadLiteral0 and Return. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1239793002 Cr-Commit-Position: refs/heads/master@{#29814}
2015-07-23 14:21:26 +00:00
"+src/interpreter/bytecodes.h",
"+src/interpreter/interpreter.h",
Create bytecode handlers and add them to the builtins table 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}
2018-08-24 16:05:10 +00:00
"+src/interpreter/interpreter-generator.h",
Reland "[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. Previously landed as 4782bc0df89 / 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}
2017-04-07 13:31:29 +00:00
"+src/interpreter/setup-interpreter.h",
[regexp] Further narrow public API and restrict includes to regexp.h 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/+/1662297 Reviewed-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}
2019-06-17 15:16:39 +00:00
"-src/regexp",
"+src/regexp/regexp.h",
"+src/regexp/regexp-stack.h",
"+src/regexp/regexp-utils.h",
[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-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}
2017-03-13 22:12:23 +00:00
"-src/trap-handler",
[wasm] Refactor trap-handler to allow an extension to windows 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}
2018-10-26 11:04:26 +00:00
"+src/trap-handler/handler-inside-posix.h",
[wasm] Implement trap handler on Windows 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}
2018-10-30 09:35:14 +00:00
"+src/trap-handler/handler-inside-win.h",
[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-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}
2017-03-13 22:12:23 +00:00
"+src/trap-handler/trap-handler.h",
Add a mode to completely deserialize scope chains 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}
2016-08-03 13:30:23 +00:00
"+testing/gtest/include/gtest/gtest_prod.h",
Split out libplatform into a separate libary Also remove the "use default platform" compile flag. Instead, the embedder has to provide the platform. Change all binaries to use the default platfrom from libplatform. Unless --job-based-sweeping is passed, nothing uses the platform yet, so nothing will break for embedders (yet). BUG=none R=jkummerow@chromium.org LOG=y Review URL: https://codereview.chromium.org/345903004 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22180 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-07-03 07:37:27 +00:00
"-src/libplatform",
[torque] refactor BUILD.gn to list torque sources in one place Change-Id: Ibb6e10caaa4fcdb29c35baef71cf1b4faef45bc4 Reviewed-on: https://chromium-review.googlesource.com/1042389 Reviewed-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}
2018-05-04 13:18:37 +00:00
"-include/libplatform",
[embedded handlers] Store the handlers without gaps 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}
2018-09-10 12:55:45 +00:00
"+builtins-generated",
[torque] refactor BUILD.gn to list torque sources in one place Change-Id: Ibb6e10caaa4fcdb29c35baef71cf1b4faef45bc4 Reviewed-on: https://chromium-review.googlesource.com/1042389 Reviewed-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}
2018-05-04 13:18:37 +00:00
"+torque-generated"
Add DEPS files and run checkdeps in presubmit check BUG=none R=jkummerow@chromium.org LOG=n Review URL: https://codereview.chromium.org/312763002 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21642 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-06-03 13:39:42 +00:00
]
Split out libplatform into a separate libary Also remove the "use default platform" compile flag. Instead, the embedder has to provide the platform. Change all binaries to use the default platfrom from libplatform. Unless --job-based-sweeping is passed, nothing uses the platform yet, so nothing will break for embedders (yet). BUG=none R=jkummerow@chromium.org LOG=y Review URL: https://codereview.chromium.org/345903004 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22180 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-07-03 07:37:27 +00:00
specific_include_rules = {
Serializer: move to a subfolder and clean up includes. R=jochen@chromium.org Review URL: https://codereview.chromium.org/1041743002 Cr-Commit-Position: refs/heads/master@{#27501}
2015-03-27 15:28:55 +00:00
"d8\.cc": [
Split out libplatform into a separate libary Also remove the "use default platform" compile flag. Instead, the embedder has to provide the platform. Change all binaries to use the default platfrom from libplatform. Unless --job-based-sweeping is passed, nothing uses the platform yet, so nothing will break for embedders (yet). BUG=none R=jkummerow@chromium.org LOG=y Review URL: https://codereview.chromium.org/345903004 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22180 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-07-03 07:37:27 +00:00
"+include/libplatform/libplatform.h",
Reland [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 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}
2016-07-27 16:21:09 +00:00
"+include/libplatform/v8-tracing.h",
[tracing] Use the new perfetto client API 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/+/1634916 Reviewed-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}
2019-07-08 08:29:54 +00:00
"+perfetto/tracing.h"
Split out libplatform into a separate libary Also remove the "use default platform" compile flag. Instead, the embedder has to provide the platform. Change all binaries to use the default platfrom from libplatform. Unless --job-based-sweeping is passed, nothing uses the platform yet, so nothing will break for embedders (yet). BUG=none R=jkummerow@chromium.org LOG=y Review URL: https://codereview.chromium.org/345903004 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22180 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-07-03 07:37:27 +00:00
],
}
Reference in New Issue Copy Permalink