[v8-dev] [Design Doc] Caching script source safely in the V8 inspector

Hey folks, I summarized the issue with the Script leak in the inspector in a doc <https://docs.google.com/document/d/1tZcF1KZSJvSKJTeBc1Cwtt2f1uPrxW0g1yXwc030auI>, and outlined the proposed solution (and alternatives we considered). Please take a look. cheers, Benedikt -- Benedikt

Re: [v8-dev] Design doc: Remove Arguments Adaptor Frame in Deoptimizer

FrameState, it's just that this was the way the world worked back when we wrote most of this code. cheers, Benedikt On Tue, Sep 22, 2020 at 10:30 AM 'Victor Gomes' via v8-dev < v8-dev@googlegroups.com> wrote: > Thanks Benedikt! > > On Mon, Sep 21, 2020 at 6:04 PM Benedikt

Re: [v8-dev] Design doc: Remove Arguments Adaptor Frame in Deoptimizer

FuzY0LLM7%2BAjoaax1usWN9Jov1eq89EvdYKdVDtdR80j5rFA%40mail.gmail.com > <https://groups.google.com/d/msgid/v8-dev/CAGFuzY0LLM7%2BAjoaax1usWN9Jov1eq89EvdYKdVDtdR80j5rFA%40mail.gmail.com?utm_medium=email_source=footer> > . > -- Benedikt Meurer Chromium DevTools TL bmeu...@chromium.org Googl

[v8-dev] Re: [devtools-dev] [RFC] DevTools Language Servers Proposal

devtools frontend through CDP? > Or are we looking to replace LLDB with our own debugger interpretation? > > Best regards, > Philip > > On Fri, Oct 11, 2019 at 8:51 AM Benedikt Meurer > wrote: > >> Hey folks, >> >> Following up on the prototyping

[v8-dev] WebAssembly Inspector Interface

I've shared an item with you: WebAssembly Inspector Interface https://docs.google.com/document/d/1zi5LLKwWMRdIIWN4Vgyy7RgcM0f4Xi3Ffn27QO1iMGU/edit?usp=sharing=5da06e9e It's not an attachment -- it's stored online. To open this item, just click the link above. Hey folks (specifically Wasm

[v8-dev] [RFC] DevTools Language Servers Proposal

it describes two possible high level solutions how to address the current problem. Please let me know what you think. cheers, Benedikt -- Benedikt Meurer Chromium DevTools TL bmeu...@chromium.org Google Germany GmbH Erika-Mann-Straße 33 80636 München Geschäftsführer: Paul Manicle, Halimah

Re: [v8-dev] Re: [blink-dev] Intent to Ship: Promise.{all, race, allSettled} optimization

cussion on the web visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMd%2BM7yLMvv55qcOXyW8o_g3sHe0mrYgT_WC%2BmE2GRrqKG-SuA%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMd%2BM7yLMvv55qcOXyW8o_g3sHe0mrYgT_WC%2BmE2GRrqK

Re: [v8-users] Re: [v8-dev] Intent to Ship: Promise.allSettled

LGTM! On Wed, Apr 24, 2019, 02:05 Adam Klein wrote: > LGTM! > > On Tue, Apr 23, 2019 at 4:19 PM Sathya Gunasekaran > wrote: > >> Contact Emails: >> gsat...@chromium.org >> >> Spec: >> https://tc39.github.io/proposal-promise-allSettled/ >> >> Summary: >> Promise.allSettled returns a promise

[v8-dev] Re: [v8-users] Re: [blink-dev] Intent to Ship: RegExp @@matchAll / String.prototype.matchAll

gt;> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAKm-Q%2BuNU%3D%2BbSgu87THKGedRbf1OuCQSsJbmRgK5iPWAVO%2BDA%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAKm-Q%2BuNU%3D%2BbSgu87THKGedRbf1OuCQSsJbmRgK5iPWAVO%2BDA%40mail.gmail.com?utm_

Re: [v8-dev] Re: performance benchmark of async-design-patterns - recursive-callbacks vs. promises vs. async/await

al.clientHttpRequest] += ' (' + >> Math.round(Math.sqrt( >> >> local.resultList[local.clientHttpRequest].reduce(function (aa, bb) { >> return aa + Math.pow( >> (bb || 0) - >> local.resultMean[local.clientHttpRe

Re: [v8-dev] A potential speedup for Promises and Async Functions

sks are run in a single JS entry, whereas in v8 ToT > you enter/exit JS thousands of times. > > Cheers, > > Yang > > On Fri, Sep 1, 2017 at 7:29 AM Benedikt Meurer <bmeu...@chromium.org> > wrote: > >> I don't think strong-rooting a JSFunction is a good

Re: [v8-dev] A potential speedup for Promises and Async Functions

ved regs are actually saved and restored. > > If I can strong-root a full JSFunction and just use the ordinary > JSEntryStub, as Adam suggested, it may be a non-issue. > > On Aug 31, 2017, at 11:00 PM, Benedikt Meurer <bmeu...@chromium.org> > wrote: > > I like the idea of bei

Re: [v8-dev] A potential speedup for Promises and Async Functions

I like the idea of being able to run microtasks from CSA land. Not sure about this JSEntryStub businesses tho, it all sounds dangerous to me. Is this just to avoid some code duplication between CSA and C++? If so, then I'd strongly recommend against it and just duplicate that logic for now. If not

Re: [v8-dev] Javascript ES6 class is slower than using ES5 prototype

that Nodev9 for both ES5 and ES6 run approximately the same speed at > 820,000 eps which is about *1.7x faster* than Nodev8 using ES5! > > Kudo's to the V8 team!! > > > On Monday, June 12, 2017 at 9:36:01 PM UTC-7, Benedikt Meurer wrote: > >> With V8 5.8, that sounds

Re: [v8-dev] Javascript ES6 class is slower than using ES5 prototype

With V8 5.8, that sounds possible. In 5.8 modern JavaScript (i.e. ES2015 and later) is sent to the new compiler pipeline (based on Ignition and TurboFan), whereas classic JavaScript is sent to the old compiler pipeline (based on FullCodegen and Crankshaft). JavaScript code is strictly divided by

Re: [v8-dev] Help to migrate JS to C++ (and contributing V8 in general)

The ObjectBuiltinsAssembler adds a couple of additional helper methods. -- Benedikt Benedikt Meurer | Software Engineer, V8 | Google Germany GmbH | Erika-Mann-Str. 33, 80636 München Registergericht und -nummer: Hamburg, HRB 86891 | Sitz der Gesellschaft: Hamburg | Geschäftsführer: Matthew

Re: [v8-dev] Help to migrate JS to C++ (and contributing V8 in general)

for the ToObject builtin (which has internal stub linkage). I don't think you need to touch src/runtime or src/debug for this. HTH, Benedikt Benedikt Meurer | Software Engineer, V8 | Google Germany GmbH | Erika-Mann-Str. 33, 80636 München Registergericht und -nummer: Hamburg, HRB 86891 | Sitz der

Re: [v8-dev] Strange code in FCG

Hey Dmitriy, Each JSObject contains at least three fields, the map, the properties backing store and the elements backing store. The first movp in the code you point to initializes the map, the next two initializes the backing stores to empty arrays. HTH, Benedikt Benedikt Meurer | Software

Re: [v8-dev] Desugaring language features in the BytecodeGenerator - Invitation to edit

Potter <caitpotte...@gmail.com> schrieb am Fr., 3. Feb. 2017, 04:26: > Sorry bout that, sharing is enabled now > > Sent from my iPhone > > On Feb 2, 2017, at 10:05 PM, Benedikt Meurer <bmeu...@chromium.org> wrote: > > Hey Caitlin, > > Can you enable li

Re: [v8-dev] Desugaring language features in the BytecodeGenerator - Invitation to edit

Hey Caitlin, Can you enable link sharing for the doc? -- Benedikt Caitlin Potter (via Google Docs) schrieb am Fr., 3. Feb. 2017, 00:36: > Caitlin Potter has invited you to *edit* the following > document: > Desugaring language features in the

Re: [v8-dev] Type feedback slot allocation

Indeed. We need to kill FCG+CS first. I was wondering about the same for ToBoolean feedback in Ignition, where only Ignition knows whether it really needs a slot. -- Benedikt 'Ross McIlroy' via v8-dev schrieb am Mi., 7. Dez. 2016, 19:39: > Hi Caitlin, > > As I

Re: [v8-dev] Builtins are always sloppy mode?

Hey Adam, I think that this is not even consistent; as you point out, some builtins are strict (the js ones), while others are sloppy. I think this is for historical reasons, because initially everything was sloppy, and then we migrated some of the js files to strict mode. But so far no one payed

Re: [v8-dev] FLAG_trace_turbo_reduction and tracing various reducers

Hey Deon, No there's currently no way to trace reducers in general. The --trace-turbo-graph flag prints out the full graph after every pass, once all the reductions in that pass happened, but I suppose that's not what you were looking for. -- Benedikt Deon Dior schrieb

Re: [v8-dev] Re: [blink-dev] Intent to Un-ship: Non-standard Promise functions

Awesome! Thanks for taking care of this, Dan. On Wed, May 11, 2016 at 7:54 AM, 'Daniel Ehrenberg' via v8-dev < v8-dev@googlegroups.com> wrote: > I ended up adding UseCounters and waiting for results to come in. Finally, > they did: none of these three methods were used very much, the most >

Re: [v8-dev] why TurboFan not kicking in on first run of asm.js function?

Hey Yang, Currently asm.js still goes through the full JavaScript pipeline in TurboFan, which turned out to be too expensive for AOT. Hence we start with fullcodegen and only tier up to TurboFan if the function becomes hot. This will change soon once the asm.js verfier is enabled. Then asm.js

Re: [v8-dev] Are there different optimization levels in Turbofan?

Hey Deon, The whole so called "typed pipeline" (initially enabled via --turbo-types) is optional in theory, which means that only the "generic pipeline" (consisting only of graph building and generic lowering) runs. This doesn't make sense in practice though as the generated code is then

Re: [v8-dev] Polyfill Optimizations

Hey Robert, It depends on the context: if your x is a property of the global object, then V8 still optimizes Math.pow in your example. Even if it's a local variable, we might still be able to optimize this in many cases. But to answer your question: The polyfill assignment won't break the

Re: [v8-dev] Optimizing Atomics for TurboFan

YI, another wrinkle: MSVC doesn't support inline assembly for x64 >> targets <https://msdn.microsoft.com/en-us/library/wbk4z78b.aspx>. :-| >> >> Sounds like the suggested workaround is intrinsics or using the assembler >> directly. >> >> On Monday, Janua

Re: [v8-dev] Can we move the lists of interned Strings and Symbols out of heap/heap.h?

Yeah, we talked about that offline before Christmas and mostly agreed that we should do it soonish. Yang Guo schrieb am Mi., 6. Jan. 2016, 22:02: > Ive had thoughts about this as well, and it indeed makes sense. SGTM. > > Yang > > On Wed, Jan 6, 2016, 20:00 'Adam Klein'

Re: [v8-dev] Optimizing Atomics for TurboFan

Hm, skipping those tests in the simulators could easily backfire. Let's just do the runtime function approach and see how far we can get. -- Benedikt Ben Smith <bi...@chromium.org> schrieb am Mo., 4. Jan. 2016, 22:05: > > > On Tuesday, December 29, 2015 at 9:07:15 PM UTC-8,

Re: [v8-dev] Optimizing Atomics for TurboFan

22:35: > On Thursday, December 17, 2015 at 2:17:01 PM UTC-8, Ben Smith wrote: >> >> >> >> On Thursday, December 17, 2015 at 11:26:48 AM UTC-8, Benedikt Meurer >> wrote: >>> >>> Can't you use the same instruction sequence, even from C++ code? >>&

Re: [v8-dev] Optimizing Atomics for TurboFan

sure to generate the exactly the same instructions I guess? IIRC Jaro thought about this already, maybe he can give some advice. On Thu, Dec 17, 2015 at 8:06 PM, Ben Smith <bi...@chromium.org> wrote: > > > On Wednesday, December 16, 2015 at 7:16:07 PM UTC-8, Benedikt Meurer w

Re: [v8-dev] Optimizing Atomics for TurboFan

You probably need the same guarantees for CS. So how about putting them into a code stub? And calling the stub for the %_ cases in all three compilers? BTW wouldn't it work if FCG always uses the C++ version? -- Benedikt Ben Smith schrieb am Do., 17. Dez. 2015, 00:01: > Hi

Re: [v8-dev] Re: An update on bit_cast

How about adding overloads for the template with pointers w/o implementation? On Wed, Dec 9, 2015 at 10:59 AM, 'Erik Corry' via v8-dev < v8-dev@googlegroups.com> wrote: > Yes. We plan to put in asserts to prevent it being used for pointer types. > > On 4 December 2015 at 15:30, Jochen Eisinger

Re: [v8-dev] Math.random

This is creating a lot of noise in mainstream media, I.e. http://m.heise.de/newsticker/meldung/JavaScript-Engine-V8-Vorsicht-vor-Math-random-3010353.html Jakob Kummerow schrieb am Fr., 20. Nov. 2015, 16:10: > Observe https://codereview.chromium.org/1462293002 which

Re: [v8-dev] RFC: Deprecate runtime asserts that throw "illegal access" string

SGTM On Thu, Oct 15, 2015 at 3:21 PM, Yang Guo wrote: > I agree, if Clusterfuzz no longer directly calls runtime functions with > weird arguments anymore. > > On Thu, Oct 15, 2015 at 3:16 PM Michael Starzinger < > mstarzin...@chromium.org> wrote: > >> *TL;DR*: I propose to

Re: [v8-dev] C++ implementations [was: Code structure bikeshed: Where should spec reference implementations live?]

I had a quick look at the Promises code and I think a lot of that would actually benefit from being rewritten in C++. I don't know yet about the typed array code. 'Daniel Ehrenberg' via v8-dev schrieb am Fr., 2. Okt. 2015, 03:27: > On Sat, Sep 26, 2015 at 5:44 AM, Jakob

Re: [v8-dev] Code structure bikeshed: Where should spec reference implementations live?

AFAIK everyone is doing (1) currently, and so at least for now, which is kinda what we agreed on some time ago. I don't see why we have to change that now. I think (3) is essentially (2) with a different directory/base filename, and many people thought that (2) was bad, which AFAIR is why we are

Re: [v8-dev] Code structure bikeshed: Where should spec reference implementations live?

One important bit tho: The (static) methods should be somewhere close the classes they relate to, otherwise we just go back to runtime-*.cc. On Fri, Sep 25, 2015 at 1:37 PM, Benedikt Meurer <bmeu...@chromium.org> wrote: > AFAIK everyone is doing (1) currently, and so at least for n

[v8-dev] [mjsunit] Remove unsupported flag --turbo-deoptimization from tests. (issue 1183123002 by bmeu...@chromium.org)

Reviewers: Sven Panne, Description: [mjsunit] Remove unsupported flag --turbo-deoptimization from tests. R=svenpa...@chromium.org Please review this at https://codereview.chromium.org/1183123002/ Base URL: https://chromium.googlesource.com/v8/v8.git@master Affected files (+18, -43 lines):

[v8-dev] [mjsunit] regress/regress-crbug-491062 takes too long with --always-opt. (issue 1183133002 by bmeu...@chromium.org)

Reviewers: Igor Sheludko, Description: [mjsunit] regress/regress-crbug-491062 takes too long with --always-opt. R=ish...@chromium.org Please review this at https://codereview.chromium.org/1183133002/ Base URL: https://chromium.googlesource.com/v8/v8.git@master Affected files (+1, -1 lines):

[v8-dev] [mjsunit] Remove obsolete nosse2 tests. (issue 1186713003 by bmeu...@chromium.org)

Reviewers: Sven Panne, Description: [mjsunit] Remove obsolete nosse2 tests. R=svenpa...@chromium.org Please review this at https://codereview.chromium.org/1186713003/ Base URL: https://chromium.googlesource.com/v8/v8.git@master Affected files (+1, -883 lines): D

[v8-dev] [turbofan] Remove context canonicalization hack from generic lowering. (issue 1177033006 by bmeu...@chromium.org)

Reviewers: Michael Starzinger, Description: [turbofan] Remove context canonicalization hack from generic lowering. This hack doesn't help currently, since it only applies to asm.js where we do function context specialization and there we already have a canonicalized context (and the

[v8-dev] [turbofan] Remove the TryLowerDirectJSCall hack from generic lowering. (issue 1182193005 by bmeu...@chromium.org)

Reviewers: Michael Starzinger, Description: [turbofan] Remove the TryLowerDirectJSCall hack from generic lowering. The TryLowerDirectJSCall method tried to lower to a direct JavaScript function call depending on the type of the receiver, but only if the target is a cosntant JSFunction. Since

[v8-dev] Re: Greedy allocator: perf work (issue 1157663007 by mtro...@chromium.org)

Hey Mircea, I think I just came up with a good criteria for a new register allocator: It should be possible to add stack checks to every loop in asm.js code without noticable performance impact. Currently we skip the stack checks for asm.js functions because the spilling around the stack check

[v8-dev] [turbofan] Remove unused typedef VirtualRegisterSet. (issue 1179913003 by bmeu...@chromium.org)

Reviewers: Sven Panne, Description: [turbofan] Remove unused typedef VirtualRegisterSet. TBR=svenpa...@chromium.org Please review this at https://codereview.chromium.org/1179913003/ Base URL: https://chromium.googlesource.com/v8/v8.git@master Affected files (+0, -1 lines): M

[v8-dev] [turbofan] Mark MachineType as uint16_t. (issue 1182303003 by bmeu...@chromium.org)

Reviewers: Sven Panne, Description: [turbofan] Mark MachineType as uint16_t. This fixes a few funky implicit conversions for the enum (that are inconsistent across compilers) and also helps to save space, i.e. for the representations_ vector in the InstructionSequence. R=svenpa...@chromium.org

[v8-dev] [turbofan] Use appropriate type for NodeId. (issue 1178403004 by bmeu...@chromium.org)

Reviewers: Sven Panne, Description: [turbofan] Use appropriate type for NodeId. Up until now we used int32_t for NodeId, but that was not ideal because negative values are invalid for NodeId and we use it as an array index for example in the NodeMarker class, where C++ compilers on x64 have to

[v8-dev] [heap] All immutable roots are either smis or immovable heap objects. (issue 1180043002 by bmeu...@chromium.org)

Reviewers: Yang, Description: [heap] All immutable roots are either smis or immovable heap objects. R=yang...@chromium.org Please review this at https://codereview.chromium.org/1180043002/ Base URL: https://chromium.googlesource.com/v8/v8.git@master Affected files (+5, -2 lines): M

[v8-dev] Re: [turbofan] Inline hot functions for NodeMarkerBase. (issue 1184693002 by bmeu...@chromium.org)

Committed patchset #1 (id:1) manually as bd3edf37e1a1ecf158b1ec57904558b5afddd5e3 (presubmit successful). https://codereview.chromium.org/1184693002/ -- -- v8-dev mailing list v8-dev@googlegroups.com http://groups.google.com/group/v8-dev --- You received this message because you are subscribed

[v8-dev] [turbofan] Inline hot functions for NodeMarkerBase. (issue 1184693002 by bmeu...@chromium.org)

Reviewers: jarin, Description: [turbofan] Inline hot functions for NodeMarkerBase. R=ja...@chromium.org Please review this at https://codereview.chromium.org/1184693002/ Base URL: https://chromium.googlesource.com/v8/v8.git@master Affected files (+18, -32 lines): M

[v8-dev] [turbofan] Move RawMachineAssembler to unittests. (issue 1177353003 by bmeu...@chromium.org)

Reviewers: Michael Starzinger, Description: [turbofan] Move RawMachineAssembler to unittests. R=mstarzin...@chromium.org Please review this at https://codereview.chromium.org/1177353003/ Base URL: https://chromium.googlesource.com/v8/v8.git@master Affected files (+6, -844 lines): M

[v8-dev] [turbofan] Materialize all from non-writable roots from root array. (issue 1175113005 by bmeu...@chromium.org)

Reviewers: jarin, Description: [turbofan] Materialize all from non-writable roots from root array. R=ja...@chromium.org Please review this at https://codereview.chromium.org/1175113005/ Base URL: https://chromium.googlesource.com/v8/v8.git@master Affected files (+10, -19 lines): M

[v8-dev] [turbofan] Use RootIndexMap to speed up IsMaterializableFromRoot predicate. (issue 1181123002 by bmeu...@chromium.org)

Reviewers: jarin, Description: [turbofan] Use RootIndexMap to speed up IsMaterializableFromRoot predicate. R=ja...@chromium.org Please review this at https://codereview.chromium.org/1181123002/ Base URL: https://chromium.googlesource.com/v8/v8.git@master Affected files (+9, -13 lines): M

[v8-dev] [heap] Unify the immortal immovable root detection mechanism. (issue 1178853002 by bmeu...@chromium.org)

Reviewers: jarin, Description: [heap] Unify the immortal immovable root detection mechanism. Uniformly use the Heap::GetRootListIndex() and Heap::RootIsImmortalImmovable() methods to detect immortal immovable roots in the optimizing compilers. R=ja...@chromium.org Please review this at

[v8-dev] [deoptimizer] Basic support inlining based on SharedFunctionInfo. (issue 1169103004 by bmeu...@chromium.org)

Reviewers: jarin, Description: [deoptimizer] Basic support inlining based on SharedFunctionInfo. Up until now we can only inline based on JSFunction, because of the way the deoptimization works. With this change we will be able to inline based on the SharedFunctionInfo and materialize the

[v8-dev] [turbofan] Record the SharedFunctionInfo of ALL inlined functions. (issue 1175953002 by bmeu...@chromium.org)

Reviewers: Michael Starzinger, Description: [turbofan] Record the SharedFunctionInfo of ALL inlined functions. Previously we only recorded the SharedFunctionInfo of inlined functions that had at least one (lazy) deopt point left at code generation time. R=mstarzin...@chromium.org Please

[v8-dev] [stl] Fix ZonePriorityQueue wrapper. (issue 1179763002 by bmeu...@chromium.org)

Reviewers: jarin, Description: [stl] Fix ZonePriorityQueue wrapper. R=ja...@chromium.org Please review this at https://codereview.chromium.org/1179763002/ Base URL: https://chromium.googlesource.com/v8/v8.git@master Affected files (+4, -2 lines): M src/zone-containers.h Index:

[v8-dev] Re: [turbofan] Record the SharedFunctionInfo of ALL inlined functions. (issue 1175953002 by bmeu...@chromium.org)

Committed patchset #2 (id:20001) manually as ffa0b4007cd7de0cfd6d37079ef360e3beeb5686 (presubmit successful). https://codereview.chromium.org/1175953002/ -- -- v8-dev mailing list v8-dev@googlegroups.com http://groups.google.com/group/v8-dev --- You received this message because you are

[v8-dev] [frames] Remove obsolete JavaScriptFrame::GetInlineCount() method. (issue 1176473002 by bmeu...@chromium.org)

Reviewers: Michael Starzinger, Description: [frames] Remove obsolete JavaScriptFrame::GetInlineCount() method. R=mstarzin...@chromium.org Please review this at https://codereview.chromium.org/1176473002/ Base URL: https://chromium.googlesource.com/v8/v8.git@master Affected files (+7, -33

[v8-dev] [deoptimizer] Remove uses of TranslationIterator outside the deoptimizer. (issue 1166353004 by bmeu...@chromium.org)

Reviewers: jarin, Description: [deoptimizer] Remove uses of TranslationIterator outside the deoptimizer. Use the new TranslatedState and friends, which work at a higher level than the TranslationIterator, which will make it easier to change the deoptimization commands in subsequent CLs.

[v8-dev] Re: [frames] No GC is allowed while using the unhandlified TranslatedState. (issue 1174593003 by bmeu...@chromium.org)

Committed patchset #1 (id:1) manually as 472b147708ba585f07c0020434302d96867cbb61 (presubmit successful). https://codereview.chromium.org/1174593003/ -- -- v8-dev mailing list v8-dev@googlegroups.com http://groups.google.com/group/v8-dev --- You received this message because you are subscribed

[v8-dev] [frames] No GC is allowed while using the unhandlified TranslatedState. (issue 1174593003 by bmeu...@chromium.org)

Reviewers: jarin, Description: [frames] No GC is allowed while using the unhandlified TranslatedState. R=ja...@chromium.org Please review this at https://codereview.chromium.org/1174593003/ Base URL: https://chromium.googlesource.com/v8/v8.git@master Affected files (+2, -0 lines): M

[v8-dev] [for-in] Make ForInNext and ForInFilter deal properly with exceptions. (issue 1162833006 by bmeu...@chromium.org)

Reviewers: jarin, Description: [for-in] Make ForInNext and ForInFilter deal properly with exceptions. Both ToName() and HasProperty() can actually throw, so we need to propagate those exceptions properly. BUG=chromium:496331 LOG=y R=ja...@chromium.org Please review this at

[v8-dev] [turbofan] Initial support for the %_DateField intrinsic. (issue 1169723002 by bmeu...@chromium.org)

Reviewers: jarin, Description: [turbofan] Initial support for the %_DateField intrinsic. This only introduces better typing and lowering for access to the value field. R=ja...@chromium.org Please review this at https://codereview.chromium.org/1169723002/ Base URL:

[v8-dev] Re: [turbofan] Initial support for the %_DateField intrinsic. (issue 1169723002 by bmeu...@chromium.org)

Committed patchset #2 (id:20001) manually as 5eafd7a3d95d9ed1e5f1f11a1ea408a1415da2a8 (presubmit successful). https://codereview.chromium.org/1169723002/ -- -- v8-dev mailing list v8-dev@googlegroups.com http://groups.google.com/group/v8-dev --- You received this message because you are

[v8-dev] [x64] Smi zero can be used as an immediate. (issue 1150853009 by bmeu...@chromium.org)

Reviewers: jarin, Description: [x64] Smi zero can be used as an immediate. R=ja...@chromium.org Please review this at https://codereview.chromium.org/1150853009/ Base URL: https://chromium.googlesource.com/v8/v8.git@master Affected files (+10, -1 lines): M

[v8-dev] [date] Refactor the %_DateField intrinsic to be optimizable. (issue 1167813003 by bmeu...@chromium.org)

Reviewers: Jakob, Description: [date] Refactor the %_DateField intrinsic to be optimizable. Previously the %_DateField intrinsic would also check the object and throw an exception if you happen to pass something that is not a valid JSDate, which (a) violates our policy for instrinsics and (b)

[v8-dev] [turbofan] Don't lower to NumberModulus unless the inputs are numbers. (issue 1170433002 by bmeu...@chromium.org)

Reviewers: jarin, Description: [turbofan] Don't lower to NumberModulus unless the inputs are numbers. The IC for modulus is usually way faster than converting the inputs to numbers and doing a Float64Mod on them. R=ja...@chromium.org Please review this at

[v8-dev] [turbofan] Use reference equal to zero instead of a smi check. (issue 1163963003 by bmeu...@chromium.org)

Reviewers: Michael Starzinger, Description: [turbofan] Use reference equal to zero instead of a smi check. In typed lowering we can use the ReferenceEqual simplified operator instead of ObjectIsSmi to check for context extensions. This generates the desired code. TBR=mstarzin...@chromium.org

[v8-dev] [turbofan] Enable typed lowering of string addition. (issue 1164743002 by bmeu...@chromium.org)

Reviewers: jarin, Description: [turbofan] Enable typed lowering of string addition. Unfortunately StringAdd is not pure in V8 because we might throw an exception if the resulting string length is outside the valid bounds, so there's no point in having a simplified StringAdd operator.

[v8-dev] [turbofan] Specify better type for FixedArray::length field. (issue 1162163003 by bmeu...@chromium.org)

Reviewers: jarin, Description: [turbofan] Specify better type for FixedArray::length field. This avoids redundant smi checks when using the length of a FixedArray, which is always a positve smi. R=ja...@chromium.org Please review this at https://codereview.chromium.org/1162163003/ Base URL:

[v8-dev] [turbofan] First step towards sanitizing for-in and making it optimizable. (issue 1160983004 by bmeu...@chromium.org)

Reviewers: jarin, Description: [turbofan] First step towards sanitizing for-in and making it optimizable. R=ja...@chromium.org Please review this at https://codereview.chromium.org/1160983004/ Base URL: https://chromium.googlesource.com/v8/v8.git@master Affected files (+360, -202 lines): M

[v8-dev] [crankshaft] Fix some useless deopts in for-in. (issue 1157423003 by bmeu...@chromium.org)

Reviewers: jarin, Description: [crankshaft] Fix some useless deopts in for-in. The one in lithium codegen for x64 was probably an oversight during refactoring. R=ja...@chromium.org Please review this at https://codereview.chromium.org/1157423003/ Base URL:

[v8-dev] [turbofan] Remove the useless SimplifiedOperatorReducer. (issue 1162563002 by bmeu...@chromium.org)

Reviewers: jarin, Description: [turbofan] Remove the useless SimplifiedOperatorReducer. The SimplifiedOperatorReducer is (mostly) unused, except for the very rough store elimination, and just eats compilation time. R=ja...@chromium.org Please review this at

[v8-dev] [turbofan] Remove the JSGraph dependency from the ControlFlowOptimizer. (issue 1160863003 by bmeu...@chromium.org)

Reviewers: jarin, Description: [turbofan] Remove the JSGraph dependency from the ControlFlowOptimizer. The control flow optimization should work independent of the JSGraph. We used the JSGraph there because it was convinient, not because it was necessary. R=ja...@chromium.org Please review

[v8-dev] [crankshaft] Record inlined shared function infos instead of closures. (issue 1145893003 by bmeu...@chromium.org)

Reviewers: jarin, Description: [crankshaft] Record inlined shared function infos instead of closures. The list of inlined functions is used in exactly two places - for live edit and to prevent code flushing for inlined functions - and those are fine with SharedFunctionInfo and don't require a

[v8-dev] [turbofan] Record SharedFunctionInfo of inlined functions. (issue 1156403002 by bmeu...@chromium.org)

Reviewers: jarin, Description: [turbofan] Record SharedFunctionInfo of inlined functions. We need the shared function info of inlined functions to prevent code flushing for their unoptimized code, and also to make sure that liveedit can find the proper functions to deoptimize.

[v8-dev] [deoptimizer] Materialize double values as smis whenever possible. (issue 1156393002 by bmeu...@chromium.org)

Reviewers: jarin, Description: [deoptimizer] Materialize double values as smis whenever possible. R=ja...@chromium.org Please review this at https://codereview.chromium.org/1156393002/ Base URL: https://chromium.googlesource.com/v8/v8.git@master Affected files (+48, -14 lines): M

[v8-dev] [turbofan] Simplify graph construction for for-in. (issue 1153403002 by bmeu...@chromium.org)

Reviewers: jarin, Description: [turbofan] Simplify graph construction for for-in. This is an initial step towards a faster and less incorrect implementation of for-in in TurboFan. R=ja...@chromium.org Please review this at https://codereview.chromium.org/1153403002/ Base URL:

[v8-dev] [turbofan] Use Start as sentinel for frame states. (issue 1146403008 by bmeu...@chromium.org)

Reviewers: Michael Starzinger, Description: [turbofan] Use Start as sentinel for frame states. This simplifies inlining, in that we only need to update uses of Start and inputs of End instead of walking the whole inlinee to update all outer frame states. R=mstarzin...@chromium.org Please

[v8-dev] [turbofan] Remove frame state TODOs from VisitForInBody. (issue 1148323003 by bmeu...@chromium.org)

Reviewers: jarin, Description: [turbofan] Remove frame state TODOs from VisitForInBody. Neither the increment nor the comparison can deoptimize, so we don't need proper frame states there. R=ja...@chromium.org Please review this at https://codereview.chromium.org/1148323003/ Base URL:

[v8-dev] [turbofan] Optimize and || in test context. (issue 1160683003 by bmeu...@chromium.org)

Reviewers: Michael Starzinger, Description: [turbofan] Optimize and || in test context. R=mstarzin...@chromium.org Please review this at https://codereview.chromium.org/1160683003/ Base URL: https://chromium.googlesource.com/v8/v8.git@master Affected files (+4, -0 lines): M

[v8-dev] [turbofan] Change End to take a variable number of inputs. (issue 1157023002 by bmeu...@chromium.org)

Reviewers: Michael Starzinger, Description: [turbofan] Change End to take a variable number of inputs. This simplifies the handling of the End node. Based on this CL we will finally fix terminating every loop from the beginning (via Terminate nodes) and fix inlining of Throw, Deoptimize and

[v8-dev] [turbofan] Properly kill Terminate nodes when removing loops. (issue 1161583002 by bmeu...@chromium.org)

Reviewers: jarin, Description: [turbofan] Properly kill Terminate nodes when removing loops. BUG=chromium:491578 LOG=n R=ja...@chromium.org Please review this at https://codereview.chromium.org/1161583002/ Base URL: https://chromium.googlesource.com/v8/v8.git@master Affected files (+18, -7

[v8-dev] [turbofan] Connect loops to end via Terminate during graph building. (issue 1155683004 by bmeu...@chromium.org)

Reviewers: Michael Starzinger, Description: [turbofan] Connect loops to end via Terminate during graph building. This way we don't need to connect (potentially) non-terminating loops later during control reduction, which saves one forward pass over the control graph. Long term we will move the

[v8-dev] [turbofan] Don't mix up name/property accesses. (issue 1149663003 by bmeu...@chromium.org)

Reviewers: Michael Starzinger, Description: [turbofan] Don't mix up name/property accesses. R=mstarzin...@chromium.org Please review this at https://codereview.chromium.org/1149663003/ Base URL: https://chromium.googlesource.com/v8/v8.git@master Affected files (+17, -78 lines): M

[v8-dev] [turbofan] Enable deoptimization for non-asm.js TurboFan code. (issue 1153483002 by bmeu...@chromium.org)

Reviewers: jarin, Description: [turbofan] Enable deoptimization for non-asm.js TurboFan code. Replace the --turbo-deoptimization flag with --turbo-asm-deoptimization and enable deoptimization for non-asm.js TurboFan code unconditionally. R=ja...@chromium.org Please review this at

[v8-dev] [turbofan] --turbo should not imply --turbo-type-feedback. (issue 1150923005 by bmeu...@chromium.org)

Reviewers: Michael Starzinger, Description: [turbofan] --turbo should not imply --turbo-type-feedback. The --turbo flag should reflect our TurboFan staging configuration, and for now that does not include the JSTypeFeedbackSpecializer. R=mstarzin...@chromium.org Please review this at

[v8-dev] Re: [turbofan] --turbo should not imply --turbo-type-feedback. (issue 1150923005 by bmeu...@chromium.org)

Committed patchset #1 (id:1) manually as f2ffa6ade5e28d6ff1ed8895e320fc77bfb08c68 (presubmit successful). https://codereview.chromium.org/1150923005/ -- -- v8-dev mailing list v8-dev@googlegroups.com http://groups.google.com/group/v8-dev --- You received this message because you are subscribed

[v8-dev] [turbofan] Fix UnifyReturn magic in the inliner. (issue 1146393002 by bmeu...@chromium.org)

Reviewers: Michael Starzinger, Description: [turbofan] Fix UnifyReturn magic in the inliner. The inliner previously assumed that there will only be returns reaching the end node, but that's not true. This refactoring will make it possible to also hook up Deoptimize, Throw and Terminate nodes

[v8-dev] [turbofan] Add streaming operator for opcodes to ease debugging. (issue 1147973002 by bmeu...@chromium.org)

Reviewers: Michael Starzinger, Description: [turbofan] Add streaming operator for opcodes to ease debugging. R=mstarzin...@chromium.org Please review this at https://codereview.chromium.org/1147973002/ Base URL: https://chromium.googlesource.com/v8/v8.git@master Affected files (+10, -0

[v8-dev] [turbofan] Pass deoptimization mode to type feedback specializer. (issue 1145143002 by bmeu...@chromium.org)

Reviewers: jarin, Description: [turbofan] Pass deoptimization mode to type feedback specializer. R=ja...@chromium.org Please review this at https://codereview.chromium.org/1145143002/ Base URL: https://chromium.googlesource.com/v8/v8.git@master Affected files (+229, -160 lines): M

[v8-dev] [turbofan] Pass deoptimization mode to intrinsic lowering. (issue 1148033002 by bmeu...@chromium.org)

Reviewers: jarin, Description: [turbofan] Pass deoptimization mode to intrinsic lowering. R=ja...@chromium.org Please review this at https://codereview.chromium.org/1148033002/ Base URL: https://chromium.googlesource.com/v8/v8.git@master Affected files (+18, -8 lines): M

[v8-dev] [turbofan] Carefully update frame states during inlining. (issue 1134973006 by bmeu...@chromium.org)

Reviewers: jarin, Description: [turbofan] Carefully update frame states during inlining. During inlining we should pay attention to only rewire the outer frame states of the inlinee, but leave any inner frame states of the inlinee untouched. Otherwise we might run into trouble once we start