- 23 May, 2019 1 commit
-
-
Yang Guo authored
TBR=bmeurer@chromium.org,leszeks@chromium.org Bug: v8:9247 Change-Id: I8d14d0192ea8c705f8274e8e61a162531826edb6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1624220Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#61769}
-
- 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}
-
- 15 Mar, 2019 1 commit
-
-
Clemens Hammacher authored
This asserts that we run e.g. GC finalization tasks. Without that, we might run ouf of memory. R=ahaas@chromium.org Bug: chromium:938739 Change-Id: Ic80074f877183bcabb3353fbeff94842a534efab Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1526007Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#60266}
-
- 09 Aug, 2018 1 commit
-
-
Ben L. Titzer authored
This CL introduces a set of configuration options implemented as a struct of booleans that together comprise the set of enabled or detected features. The configuration options replace command-line flags that were checked deep in the implementation. As such, it is necessary to plumb them through multiple levels of abstraction. R=ahaas@chromium.org CC=mstarzinger@chromium.org BUG=chromium:868844 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I1b82f5826e4fd263f68e8cafcd923bac5818a637 Reviewed-on: https://chromium-review.googlesource.com/1163670Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#55018}
-
- 21 Jun, 2018 1 commit
-
-
Clemens Hammacher authored
Other fuzzers already have this ability. This CL adds it to the fuzzer. The input has to be valid bytes, otherwise we cannot generate the text representation. R=titzer@chromium.org CC=gdeepti@chromium.org Change-Id: If1ba8accc707bee3b042e93f4201949f0233c90e Reviewed-on: https://chromium-review.googlesource.com/1109794 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#53926}
-
- 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}
-
- 18 Jan, 2018 1 commit
-
-
Ben L. Titzer authored
This is a further step to separate the implementation of the JavaScript API from the internals of the WASM implementation. Now, wasm-js.cc only needs to interact with the WASM engine and is (almost) independent of module-decoder.h and module-compiler.h. Also, move SyncCompileAndInstantiate() into wasm-module-runner.cc. Bug: v8:7316 R=clemensh@chromium.org, mstarzinger@chromium.org Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I7765af54ac16f53a5ff88c17a22c5d36bacaf926 Reviewed-on: https://chromium-review.googlesource.com/870871 Commit-Queue: Ben Titzer <titzer@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#50679}
-
- 28 Sep, 2017 1 commit
-
-
Ben L. Titzer authored
Note that this also makes it possible to move several classes into the module-compiler.cc file and inline their implementations. This also allows removing several uses of wasm-module.h from other places in V8 that include wasm-objects.h. R=yangguo@chromium.org,clemensh@chromium.org,ahaas@chromium.org Bug: Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I303ee2bb49dc53c951d377a1b65699c1e0e91da7 Reviewed-on: https://chromium-review.googlesource.com/687494Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#48204}
-
- 07 Sep, 2017 1 commit
-
-
Andreas Haas authored
The wasm-async fuzzer uses the bytes provided by the fuzzer engine directly as wasm module bytes, compiles them with async compilation, and then tries to execute the "main" function of the module. This "main" can have an infinite loop which causes a timeout in the fuzzer. With this CL the "main" function is first executed with the interpreter. If the execution in the interpreter finishes within 16k steps, which means that there is no infinite loop, also the compiled code is executed. I added the raw fuzzer input as a test case because in this case I really want to test the fuzzer and not V8. R=clemensh@chromium.org Bug: chromium:761784 Change-Id: Id1fe5da0da8670ec821ab9979fdb9454dbde1162 Reviewed-on: https://chromium-review.googlesource.com/651046 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#47874}
-
- 12 Jun, 2017 2 commits
-
-
Andreas Haas authored
The EnableFlagScope is useful also for non-boolean flags. With the template we can use if for example in the wasm fuzzers to reduce the maximum memory size of a wasm module. In addition I put the EnableFlagScope into the v8::internal namespace, and I fixed a small typo. BUG=v8:6474 R=clemensh@chromium.org Change-Id: Iae5d5c058c334cd0f9e09d20adfd229fc2d6c585 Reviewed-on: https://chromium-review.googlesource.com/531005 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#45862}
-
Clemens Hammacher authored
This is a testing-only function, which is semantically equivalent to a SyncCompile followed by SyncInstantiate. We add a new SyncCompileAndInstantiate function to do those two steps in one go, and use this method instead. For AsmJs modules, a new testing function CompileAndRunAsmWasmModule is introduced. This is part of our effort to reduce the number of special paths for testing. It is connected with https://chromium-review.googlesource.com/529210, but should not conflict with it. After landing both CLs, we can later also get rid of InstantiateModuleForTesting. R=ahaas@chromium.org, mtrofin@chromium.org BUG=v8:6474 Change-Id: I7891e968370d5eb68803076ce2639c65a2799dcc Reviewed-on: https://chromium-review.googlesource.com/529844Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#45852}
-
- 24 Jan, 2017 1 commit
-
-
ahaas authored
Similar to the maximum memory size this limit caused problems for the fuzzer due to oom issues. With the command line flag we can limit the maximum table size for the fuzzer. R=titzer@chromium.org Review-Url: https://codereview.chromium.org/2648223004 Cr-Commit-Position: refs/heads/master@{#42623}
-
- 23 Jan, 2017 1 commit
-
-
ahaas authored
The hardcoded constant caused a problem for the wasm fuzzer because when the maximum memory was allocated in a test case, clusterfuzz ran out of memory. with the command line flag we can set a lower limit for the fuzzer. The flag has the value of the constant as its default value, so that for everything but the fuzzers nothing should change. R=titzer@chromium.org BUG=chromium:676888 Review-Url: https://codereview.chromium.org/2626313003 Cr-Commit-Position: refs/heads/master@{#42599}
-
- 17 Sep, 2016 1 commit
-
-
gdeepti authored
test-run-wasm-module cctests broken in debug since recent refactoring changes for moving Compilation/Instantiation off the module object (https://codereview.chromium.org/2320723005). The problem here is that SetupIsolateForWasm tries to add the same property to a module_object multiple times and hits a DCHECK when this property is found on a lookup. - Fixed to use the setup method only once when CcTest::InitIsolateOnce is used. - Move setup method to test as this is only used for cctests/fuzzers. The install method should take care of this in the regular JS pipeline. R=mtrofin@chromium.org, ahaas@chromium.org Review-Url: https://codereview.chromium.org/2342263002 Cr-Commit-Position: refs/heads/master@{#39484}
-
- 14 Sep, 2016 1 commit
-
-
ahaas authored
The wasm-module-runner is used both in cctests and in fuzzers. As discussed offline, it is weird to include cctest header files in fuzzers, so I introduce a new test/common directory which contains the common files. R=titzer@chromium.org, jochen@chromium.org Review-Url: https://codereview.chromium.org/2335193002 Cr-Commit-Position: refs/heads/master@{#39411}
-
- 12 Sep, 2016 2 commits
-
-
mtrofin authored
Moved the compilation/instantiation pipeline to work off the module object (JSObject), making the compiled module data (the FixedArray) an implementation detail. This: - simplifies the code by removing duplicate decode->compile->instantiate sequences - sets up the stage for "dressing up" the runtime model with stronger typed APIs - helps relanding this CL: https://codereview.chromium.org/2305903002/. It turns out that GCs during the cloning/instantiation events cause trouble, and centering the source of truth on the module object helps address this issue. In the process, clarified cctest setup for wasm-capable isolates, and changed signatures for consistency (using ModuleOrigin througout). BUG= Review-Url: https://codereview.chromium.org/2320723005 Cr-Commit-Position: refs/heads/master@{#39360}
-
ahaas authored
With this CL the wasm-code-fuzzer first decodes and interprets the test case generated by the fuzzer. It then compiles the test case, but only executes the compiled instance if the interpretation of the test case was successful. If the compiled instance is executed, then the result of the execution is compared with the result of the interpretation. Additionally this CL refactors the CompileAndRunWasmModule function in wasm-module.cc to resuse code in the call to the interpreter. R=titzer@chromium.org Review-Url: https://codereview.chromium.org/2321443002 Cr-Commit-Position: refs/heads/master@{#39351}
-
- 22 Jun, 2016 1 commit
-
-
mtrofin authored
Remove second wasm module compilation and instantiation path that we had in CompileAndRunWasmModule and reuse the same path used by user code. BUG= Review-Url: https://codereview.chromium.org/2091533002 Cr-Commit-Position: refs/heads/master@{#37203}
-
- 03 Mar, 2016 1 commit
-
-
bradnelson authored
BUG= https://code.google.com/p/v8/issues/detail?id=4203 TEST=wasm-fuzzer R=titzer@chromium.org,kcc@chromium.org LOG=N Review URL: https://codereview.chromium.org/1760033002 Cr-Commit-Position: refs/heads/master@{#34451}
-
- 02 Mar, 2016 1 commit
-
-
bradnelson authored
Fixing a memory leak in CompileAndRunModule. BUG= https://code.google.com/p/v8/issues/detail?id=4203 TEST=wasm-fuzzer R=jochen@chromium.org,jarin@chromium.org,kcc@chromium.org,machenbach@chromium.org,titzer@chromium.org LOG=N Review URL: https://codereview.chromium.org/1738943004 Cr-Commit-Position: refs/heads/master@{#34415}
-
- 02 Feb, 2016 1 commit
-
-
jochen authored
BUG=chromium:577261 R=machenbach@chromium.org,yangguo@chromium.org LOG=n Review URL: https://codereview.chromium.org/1652963002 Cr-Commit-Position: refs/heads/master@{#33673}
-