- 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}
-
- 27 Feb, 2018 1 commit
-
-
Michael Starzinger authored
This changes the encoding of the {HandlerTable} from an array of Smi values to a byte array. It allows embedding of said array into the instruction stream of {Code} objects (similar to how safepoint tables work). For interpreted bytecode the table is attached as a {ByteArray} to the bytecode. The advantage of this approach is a more compact encoding and also the ability to move such tables easily off the GC'ed heap if needed (as is done for WebAssembly code for example). R=jarin@chromium.org Change-Id: I3320415dff69b3d1053825bda0d667a28232bf6d Reviewed-on: https://chromium-review.googlesource.com/934642 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#51589}
-
- 13 Dec, 2017 1 commit
-
-
Ross McIlroy authored
RegisterLists should only be allocated via the register allocator. To ensure this, make the RegisterList constructor private and only expose it to tests and the BytecodeRegisterAllocator. Change-Id: I09ebfc5c0f1baecfb1333fd672b96d462fd26fcf Reviewed-on: https://chromium-review.googlesource.com/822196 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#50073}
-
- 18 Aug, 2016 1 commit
-
-
rmcilroy authored
Removes all accesses to the Isolate during bytecode generation and the bytecode pipeline. Adds an DisallowIsolateAccessScope which is used to enforce this invariant within the BytecodeGenerator. BUG=v8:5203 Review-Url: https://codereview.chromium.org/2242193002 Cr-Commit-Position: refs/heads/master@{#38716}
-
- 22 Jul, 2016 1 commit
-
-
yangguo authored
This is in preparation to implementing exception prediction for async functions. Each handler table entry can now predict "caught", "uncaught", or "promise". The latter indicates that the exception will lead to a promise rejection. To mark the relevant try-catch blocks, we add a new native syntax. try { } %catch (e) { } indicates a TryCatchStatement with the "promise" prediction. The previous implementation of using the function to tell the relevant try-catch apart from inner try-catch blocks will not work for async functions since these can have inner try-catch blocks inside the same function. BUG=v8:5167 Review-Url: https://codereview.chromium.org/2161263003 Cr-Commit-Position: refs/heads/master@{#37966}
-
- 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}
-
- 14 Jul, 2016 1 commit
-
-
machenbach authored
Revert of [interpreter] Reduce dependencies in bytecodes.{h,cc} (patchset #8 id:140001 of https://codereview.chromium.org/2135273002/ ) Reason for revert: Breaks the roll, possibly win gn: https://codereview.chromium.org/2148863002/ 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} TBR=mstarzinger@chromium.org,rmcilroy@chromium.org,oth@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4280 Review-Url: https://codereview.chromium.org/2151693003 Cr-Commit-Position: refs/heads/master@{#37743}
-
- 13 Jul, 2016 1 commit
-
-
oth authored
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 Review-Url: https://codereview.chromium.org/2135273002 Cr-Commit-Position: refs/heads/master@{#37715}
-
- 05 Feb, 2016 1 commit
-
-
mstarzinger authored
This makes the field in question more generic by renaming it from the previous "depth" to "data". Pure refactoring, no function change. R=rmcilroy@chromium.org,yangguo@chromium.org Review URL: https://codereview.chromium.org/1670983003 Cr-Commit-Position: refs/heads/master@{#33779}
-
- 20 Jan, 2016 1 commit
-
-
mstarzinger authored
This implements a first version of exception handler table construction within the interpreter. Note that the local control flow for try-catch and try-finally statements is still off, and also stack unwinding does not yet respect interpreter frames. But generated handler tables should be populated correctly already. R=oth@chromium.org BUG=v8:4674 LOG=n Review URL: https://codereview.chromium.org/1607433005 Cr-Commit-Position: refs/heads/master@{#33400}
-