Re: [v8-dev] V8 WebAssmebly codegen questions - 64 bit instructions and Vectorization?

To answer one of the questions here (inline): On Tue, 10 Sep 2019 at 09:20, wrote: > Hi Clemens, > > Thanks for those really helpful pointers. > > I have continued digging into this for the last week or so, and have put > my current code up GitHub for anyone interested: >

Re: [v8-dev] v8_enable_lite_mode build fails for Android.

This was an issue with the PushMultipleTimes macro-assembler helper when --optimize-for-size was enabled (which is enabled by lite_mode). I have a fix in https://chromium-review.googlesource.com/c/v8/v8/+/1773275 Cheers, Ross On Thu, 29 Aug 2019 at 08:45, Jakob Gruber wrote: > Please file a

Re: [v8-dev] Tracing V8's heap.

+Ulan Degenbaev Hi Pierre, Have you tried the mem-infra category in chrome tracing? That should give you at least some of the items you are looking for if you select the "v8" item in a mem-infra trace event.

Re: [v8-dev] ARM64 patches for review

Hi Sirish, Thanks for your contributions. Could you link to the two patches so that I can make sure they have appropriate reviewers assigned? Cheers, Ross On Wed, 16 Jan 2019 at 15:53, wrote: > Hi all, > > Following the directions from https://v8.dev/docs/contribute, I am > putting my first

Re: [v8-dev] Is it safe to skip stack check in interpreter loop body?

We use the stack-check for various operations, like installing optimized code, running GC or terminating execution. If we skip it during loop bodies then these operations would be delayed by long-running loops, and, for example, we couldn't terminate execution of infinite loops, and we wouldn't

Re: [v8-dev] Trouble with tracing JS

Hi, A couple of possible alternatives: - if you are only interested at function level tracing, then --trace does this - It might be a bit low-level, but you can trace every bytecode that gets executed using --trace-ignition (you also need to enable a GN build arg v8_enable_trace_ignition for this

Re: [v8-dev] headless speedometer2.0

If you want a headless browser, you could try Headless Chrome . Cheers, Ross On Tue, 25 Sep 2018 at 00:08, 'Mathias Bynens' via v8-dev < v8-dev@googlegroups.com> wrote: > Speedometer is not a pure ECMAScript benchmark; it tests

Re: [v8-dev] OS version detection

Hi Bruce, I don't think we have that logic in V8. I would to expect it to be here if anywhere: https://cs.chromium.org/chromium/src/v8/src/base/platform/platform-win32.cc, but I don't see anything that provides OS version. Cheers, Ross On Thu, 23 Aug 2018 at 00:59, 'Bruce Dawson' via v8-dev <

[v8-dev]

Hi all, As part of our effort to clean up the use of deprecated APIs, we are making the change to have APIs marked V8_DEPRECATE_SOON cause compiler warnings (which are treated as errors) if called within V8 code [1]. The intention is to avoid situations where APIs are left marked as

Re: [v8-dev] Re: Massively speeding up v8 compilation!

On 21 February 2018 at 07:50, Gabriel Charette wrote: > > Ah! In a V8 checkout the default is still a plain > enable_precompiled_headers = false (@v8-team: what's the process to follow > chrome on recommended GN options?). On my repo it is "!is_official_build && !use_goma"

Re: [v8-dev] Logging V8 function calls

Hi Tobias, Native functions aren't compiled to bytecode (since they are C++ not JavaScript), so don't run through the code-path you describe in the BytecodeGenerator. Cheers, Ross On 5 December 2017 at 11:02, wrote: > Hi, > I found the trace flag (in the bytecode

Re: [v8-dev] Ideas for simplifying the various Await builtins

lest option might be to add >>> another internal TFS builtin that is called by both Uncaught and Caught >>> variants and which additionally takes a `is_predicted_as_caught` parameter. >>> You'd get the roughly 50% size reduction without having to change much >>>

Re: [v8-dev] Ideas for simplifying the various Await builtins

Hi Caitlin, I'd definitively like to avoid the need for these extra copies of the async functions to specify the catch prediction, thanks for looking into this. Option (1) seems by far the most preferable to me. I think it would be slightly more than 1 extra byte per await operation (I think you

Re: [v8-dev] Re: PSA: V8 switched to a new compiler architecture

We do notice some reductions in time spent both serializing code into the cache and deserializing it out with Ignition + Turbofan in our A/B testing in the wild due to the smaller size of Ignition's bytecode compared to machine code. Cheers Ross On 5 Apr 2017 06:35, "Yang Guo"

Re: [v8-dev] PSA: FunctionEntryHook Isolate parameter will require a no-snapshot build

+Siggi since I believe Syzygy uses the FunctionEntryHook. On 7 March 2017 at 10:27, Jakob Kummerow wrote: > The v8::Isolate::CreateParams struct that you can pass to a v8::Isolate > has an entry_hook field which can be used to specify a FunctionEntryHook > callback,

Re: [v8-dev] strict build for developers which treat non numeric values in math operations as exception

Actually a potentially easier (and more future proof since BinaryOp ICs will go away when FullCodegen is deprecated) approach would be to turn on the interpreter with the --ignition flag, and instrument the codestubs used by the binary op bytecodes (e.g., CodeStubs::AddWithFeedbackStub). Cheers

Re: [v8-dev] Type feedback slot allocation

Hi Caitlin, As I understand it, the main reason that type feedback slots are allocated during ast numbering is that it is important that all the compilers agree on which slots represent which operations. In the world of Ignition+Turbofan this isn't such a big problem since only Ignition would

Re: [v8-dev] Deprecated function in test/cctest/interpreter/generate-bytecode-expectations.cc

Sep 28, 2016 at 5:16 PM, 'Ross McIlroy' via v8-dev < > v8-dev@googlegroups.com> wrote: > >> Please assign the bug to me (rmcil...@chromium.org). >> >> Cheers, >> Ross >> >> >> On 28 September 2016 at 17:07, Jochen Eisinger <joc...@chromium

Re: [v8-dev] Deprecated function in test/cctest/interpreter/generate-bytecode-expectations.cc

Please assign the bug to me (rmcil...@chromium.org). Cheers, Ross On 28 September 2016 at 17:07, Jochen Eisinger wrote: > Please file a bug at crbug.com/v8/new > > thanks > -jochen > > On Wed, Sep 28, 2016 at 6:06 PM wrote: > >> I found

Re: [v8-dev] TemplateHashMap changes proposal

On 15 Sep 2016 9:29 a.m., wrote: > > Hi all, > > We (ignition) are looking to use base/hashmap (TemplateHashMap), but there are a couple of things that I want to change/add for efficiency's sake. Because these changes would have far-reaching effects, I wanted to send out the

Re: [v8-dev] Re: PSA: In-process stack trace dumping is changing

need this in order to symbolize (at least on Linux). > On Thu, Aug 18, 2016 at 5:57 PM 'Ross McIlroy' via v8-dev < > v8-dev@googlegroups.com> wrote: > >> This has now landed. >> >> Cheers >> >> >> Ross >> >> On 18 Aug 2016 12:56 p.m., &

[v8-dev] Re: PSA: In-process stack trace dumping is changing

This has now landed. Cheers Ross On 18 Aug 2016 12:56 p.m., "Ross McIlroy" wrote: > Hi all, > > *tldr; C stack trace output will change, but we will now get dumps on > Windows and on signals / uncaught C++ exceptions in d8.* > > I'm planing on landing

[v8-dev] PSA: In-process stack trace dumping is changing

Hi all, *tldr; C stack trace output will change, but we will now get dumps on Windows and on signals / uncaught C++ exceptions in d8.* I'm planing on landing https://codereview.chromium.org/2248393002/ sometime later today. This change removes our current DumpBacktrace code (which only worked on

Re: [v8-dev] PSA: Variant-aware test status entries are now awailable

This is great, thanks for adding the support Michael! On 5 August 2016 at 14:23, Yang Guo wrote: > Thumbs up. This is awesome. > > On Fri, Aug 5, 2016 at 3:10 PM Michael Achenbach > wrote: > >> Hi! >> >> Did you ever skip a test in a .status file?

Re: [v8-dev] Pure interpreter mode

There are a number of parts of V8 which require JITed code support even in an interpreter only mode, e.g., inline cache support (e.g., LoadIC handlers, which are snippets of code genrated at runtime to load a property from an object depending on its shape), and regexp support. In addition, even

Re: [v8-dev] test-bytecode-generator refactor

On 26 February 2016 at 21:58, Yang Guo wrote: > Imo this does have some value. E.g. the debugger depends on the code to > have a certain structure and source positions to map to certain break > locations. Parser changes that cause big changes in .golden expectations > might

Re: [v8-dev] test-bytecode-generator refactor

t looked at how the rebaseline script works. > > Yang > > > On Fri, Feb 26, 2016, 16:02 'Ross McIlroy' via v8-dev < > v8-dev@googlegroups.com> wrote: > >> The errors are produced by V8 for JavaScript errors (i.e., "Uncaught >> ReferenceError: x is not defined") w

Re: [v8-dev] test-bytecode-generator refactor

The errors are produced by V8 for JavaScript errors (i.e., "Uncaught ReferenceError: x is not defined") which are for things we are explicitly testing. We could redirect stderr to /dev/null while the tool is running (I'm assuming this is what you mean?), however if we did this then it would be

Re: [v8-dev] V8 with Ignition + TurboFan only

On 23 February 2016 at 22:47, Peter Schow wrote: > > In an effort to learn more about V8 dependencies and its startup, I've been > trying out Ignition on V8 4.10.0 (candidate) via "d8 --ignition" and was > able > to actually build V8 with full-codegen commented out and

Re: [v8-dev] PSA: Adding Ignition mjsunit and test262 tests to the CQ

PM, 'Ross McIlroy' via v8-dev < > v8-dev@googlegroups.com> wrote: > >> On 11 November 2015 at 18:23, Adam Klein <ad...@chromium.org> wrote: >> >>> On Wed, Nov 11, 2015 at 9:03 AM, Ross McIlroy <rmcil...@chromium.org> >>> wrote: >>> >

Re: [v8-dev] PSA: Adding Ignition mjsunit and test262 tests to the CQ

On 11 November 2015 at 18:23, Adam Klein wrote: > On Wed, Nov 11, 2015 at 9:03 AM, Ross McIlroy > wrote: > >> Recently we have started running a subset of the mjsunit and test262 >> tests in the Ignition interpreter on the V8 test bots. In order to

[v8-dev] Re: [Interpreter] Add support for JS calls. (issue 1323463005 by rmcil...@chromium.org)

We generally auto-roll V8 multiple times a day, so this should be in Chromium by tomorrow morning. On 17 September 2015 at 17:11, Torbjörn Granlund wrote: > Thanks for the quick fix! > > I would also appreciate of a v9 -> chromium roll could be triggered > once this CL

[v8-dev] Re: [Interpreter] Preprocessor declaraton bug

Thansks Aaron. I've fixed this in https://codereview.chromium.org/1294793002/. Cheers, Ross On 16 August 2015 at 02:39, Aaron Gray aaronng...@gmail.com wrote: Hi, Line 5 of compiler/interpreter-assembler.h #ifndef has incorrect preprocessor definition for the filename. Regards, Aaron

Re: [v8-dev] Re: Ensure that GC idle notifications either make progress or stop requesting more GCs. (issue 1042483002 by rmcil...@chromium.org)

As discussed offline, this doesn't really work (since the posting happens in Blink not V8) and doesn't really help since we aren't actually preventing reposting of the idle task, just deciding whether to post a task which causes Chrome to wakeup if it is sleeping, or wait until 'after wakeup'.

[v8-dev] Re: Contribution of PowerPC port. (issue 422063005 by andrew_...@ca.ibm.com)

Yes, that seem correct. Let me know if you have any issues doing this. On 31 July 2014 17:29, andrew_...@ca.ibm.com wrote: Would like some advice on the best way to keep this patch current relative to the bleeding edge. This set of patches will no longer cleanly apply. I'm using the git

Re: [v8-dev] Re: Cross compiling for ARM?

This should be fixed as of r22509. Cheers, Ross On 21 July 2014 09:39, Ross McIlroy rmcil...@chromium.org wrote: Yes, I'll plan to restore the convenience cross compiler detection on standalone builds sometime today. In the meantime, as Henrik mentioned, adding: export