hashseed

DevTools uses a server side model, and only after you opt in with explicit consent.

Navigate to a page, right click > inspect, open the What's New panel in DevTools.

Hi. I'm the V8 engineer who implemented the fix and wrote the blog post.

The reason the initial bug report [0] was marked as WAI but the Medium blog post got a lot more traction is very simple and much more human.

When the initial issue was filed to the chromium bug tracker, it was routed to Chrome's security team. From a security perspective, Math.random() provides no guarantees about cryptographic safety, so naturally it was marked as WAI – nobody from the V8 team actually saw this issue. One of the suggestions "3. Make crypto.random(size)" was acted upon though, and so crypto.getRandomValues() was introduced in Chrome 11, about 10 months after the issue report. In terms of specifying and introducing new Web APIs, this was incredibly fast.

After the Medium blog post was published, someone filed an issue directly to the V8 project. It did not question the spec compliance, but pointed out that the PRNG quality could be better. That nerd-sniped me into researching this topic and after reading a few papers, I implemented the fix with xorshift128+. I'm thankful that my team lead allowed me to set aside some time to work on this even though it was not on our project roadmap.

Performance regressions that could affect our benchmark performance was of course part of the consideration, but there were many options to avoid a performance regression. In V8, crossing the boundary between machine code compiled from JS to C++ runtime builtins is fairly expensive. I could have either ported xorshift128+ to assembly so that this boundary crossing was not necessary, or I could have amortized the boundary crossing cost by buffering multiple random values. I chose the latter because porting to assembly is error prone and I would have to do this for each platform. There are better options in V8 nowadays, by expressing the algorithm in an intermediate representation, but back then that was not available.

[0] https://g-issues.chromium.org/issues/40404440 [1] https://developer.mozilla.org/en-US/docs/Web/API/Crypto/getR... [2] https://g-issues.chromium.org/issues/40643979

I work on Chrome DevTools.

The reason is absolutely security concerns. You don't want to leak a function that can expose a list of all objects on the JS heap.

Chrome sets navigator.webdriver to true when controlled by automation.

Until now, bots could simply use headful mode to achieve the same effect that is now made available through the new headless implementation.

I manage the team at Google that currently owns the Puppeteer project.

The previous team that developed Puppeteer indeed moved to Microsoft and have since started Playwright.

While it is true that staffing is tight (isn't it always), the number of open issues does not tell the full story. The team has been busy with addressing technical debt that we inherited (testing, architecture, migrating to Typescript, etc) as well as investing in a standardized foundation to allow Puppeteer to work cross-browser in the future. This differs from the Playwright team's approach of shipping patched browser binaries.

There is a lot of content on V8's dev blog, with different depth, all pretty well written: https://v8.dev/blog

Impressive numbers. Did you try to use startup snapshot in V8 to improve TTI? https://v8.dev/blog/custom-startup-snapshots

V8 already employs W^X, i.e. memory pages allocated for V8's heap are either writable or executable, but not both at the same time.

You were already able to do this by loading any other kind of cached resource.

In what case should this be preferred over plain old Service Workers running on the user's browser? Latter is even lower latency and for free.

There are some features in V8 to make loading a script even faster.

I'd be glad to connect over these features on twitter (same username). I implemented them.

Chrome already caches compile result for previously visited pages to bypass the initial parsing/compiling.

Do you have any details on what could be improved wrt V8's snapshotting? We have recently extended the feature set a lot in order to be able to snapshot full Blink contexts, and there are some efforts on-going to implement that in Node.js as well. Soon crutches like electron-link won't be necessary anymore.

Some context:

https://v8project.blogspot.com/2017/05/energizing-atom-with-...

https://github.com/nodejs/node/issues/13877

iirc JSC folks are blocking explicit tailcalls on TC39

Often enough, implementing the optimal solution is not really more time-consuming than the brute force solution. Often it's not about micro-optimizations, but a difference between O(n^3) and O(n*logn).

But imagine Einstein having to look up how to derive x^2. I'd say that's a pretty close equivalent to knowing tree traversal in CS. It should just come naturally.

Yup. To some, performance is just an implementation detail, and they keep adding hooks like @@hasInstance.

Unicode properties are behind an experimental flag: --harmony-regexp-property

To clarify, this is not a real job title. Chrome and V8 blog posts are written by engineers who worked on the feature being blogged about, and can choose a funky title to go with the name :)

Implementing lookbehind by reading backwards is not more computationally expensive than reading forward. It adds some complexity to the regexp engine, yes, but that's manageable.

There are some quirks vs. stepping back and reading forward, like the article already explains.

I guess Perl initially just did not implement it this way, whatever the reason was.

Not sure. If it spins up a new V8 instance every time, then no. But I don't think that happens. It probably keeps a V8 instance around, so in-memory code caching should already work.

Edit: looking at the plv8 code, it doesn't seem to create a new Isolate for every request. So I think for the same instance of PostgreSQL the in-memory cache should also hit.

V8-based projects can benefit from this as well: http://www.hashseed.net/2015/03/improving-v8s-performance-us...