In addition to the excellent technical points that Leszek explained, I just wanted to clarify additionally that we don't have a concept of "major releases 8 -> 9" etc. V8's version numbers are assigned by adding 0.1 every six weeks, rolling from x.9 to (x+1).0. There are *zero* technical or strategic considerations going into version numbers, it's entirely mechanical and on a time-based schedule. The 8.9 -> 9.0 bump is exactly as significant as 8.8 -> 8.9 or 9.0 -> 9.1. (It's similar to the Linux kernel going from, say, 4.19 to 5.0.)
Using daily V8 snapshots in production is an interesting choice. If that works for you, great; I wouldn't recommend it, given that daily snapshots are quite severely broken every now and then. See https://v8.dev/docs/version-numbers for our official recommendation (simplified TL;DR: use what Chrome Stable uses). On Tue, Jul 20, 2021 at 12:19 PM Leszek Swirski <lesz...@chromium.org> wrote: > Hi Vitali, > > Stabilising the cached data format as-is is pretty challenging; the cache > as written is pretty much a direct field-by-field serialisation of the > internal data structures, so freezing the cache would mean freezing the > shapes of those internal objects, effectively making the internal fields an > API-level guarantee. Furthermore, it's a backdoor to a stable bytecode > format, which is something we've also pushed back on as it severely limits > our ability to work on the interpreter; if we wanted to have a slightly > weaker constraint of at least guaranteeing backwards compatibility with old > bytecode, we'd have to vastly expand our test suite with old bytecodes in > order to try to maintain this backwards compatibility, and even then I'm > not sure we could fully guarantee if there's some edge case not covered in > the test suite. Same story with porting code caches from older to newer > versions; such a port would require a mapping from old to new, which would > require a) some sort of log of what old fields/bytecodes translate to what > new ones, and b) heavy testing to make sure that this mapping is valid. > This is a big security problem; the deserialisation is pretty dumb (for > performance reasons), and just spits out data onto the V8 heap without e.g. > checking if the number of fields match. Having bugs in the old->new > mapping, or in the backwards compatibility, would open up a whole pandora's > box of security issues, where one deleted field in an edge case that tests > don't cover would become an out-of-bounds write widget. > > Given that this would greatly increase our development complexity > (maintaining a stable API is already a lot of trouble for us), would be a > big source of security issues, and I don't expect it to provide much > benefit for Chrome (since we expect websites to change more often than > Chrome versions), I don't see us either working on (or accepting patches > for) a stable or even upgradeable cache. > > I'd be curious to know if you've actually observed/measured script parse > time being a big problem, or whether you're more seeing issues due to lazy > function compilation time. We've done a lot of work on parse time in recent > years, so it's not as slow as (some) people assume. We're also prototyping > a potential stable & standardisable snapshot format for the results of > partial script execution, which could help you if you're seeing large > script "setup" code being an issue, but it wouldn't store compiled bytecode > (for the above reasons). > > I appreciate that this might be a disappointing answer for you, but having > flexibility with internal objects and bytecode is one of the things that > allows us to stay performant and secure. > > - Leszek > > On Monday, July 19, 2021 at 9:00:52 PM UTC+2 lewis....@gmail.com wrote: > >> Hi Vitali, >> >> I’m neither from the v8 team, nor an expert in this subject matter. Just >> wanted to drop an interesting project: Hermes - https://hermesengine.dev >> , a javascript engine by Facebook that is tailored for fast startup times. >> It does this by precompiling javascript into bytecode at build time. >> >> So something like this should be possible maybe. >> >> Best, >> Joe >> >> On Mon, Jul 19, 2021 at 9:32 PM Vitali Lovich <vlo...@gmail.com> wrote: >> >>> Hi, >>> >>> I wanted to kick off a discussion and solicit some thoughts on whether >>> it would be operationally feasible to try to stabilize the cached data >>> format of the compiler. >>> >>> The context is that I work on Cloudflare Workers. We'd like to increase >>> the script size we allow our customers to upload, but we have concerns >>> about the performance impact that will have (specifically script parse >>> time). One mitigation for this would be to leverage the script compiler's >>> cached data & generate the cache whenever the user uploads a script. This >>> way we can precompute the cached data on upload & deliver it alongside the >>> script. >>> >>> Unfortunately, this approach has a major stumbling block which is that >>> we track V8 releases as they're published. That means our V8 version >>> changes roughly every week which would (at best) necessitate us >>> regenerating the cache for all the scripts on a weekly basis. This adds >>> scalability & implementation complexity concerns (especially since we may >>> have multiple versions of V8 running at one time). >>> >>> I'm not looking to discuss implementation specific details, but more >>> trying to get an overview of the opinions from the talented V8 team. >>> >>> - I haven't actually examined yet what the structure of the code >>> cache actually looks like. Are there prohibitive technical blockers that >>> can't really be resolved that make this a non-starter? >>> - Are there meaningful maintenance/security/implementation concerns? >>> I'm assuming there are very good reasons why the data is version locked. >>> - It's not necessarily a requirement to freeze it for all time >>> (although that would of course be ideal). What is the cadence for this >>> format actually changing (vs no-op version bumps for safety)? Would it be >>> possible to stabilize within a major V8 release (8->9, 9->10, etc) or >>> for 6 >>> month periods? >>> - If stabilizing is truly impossible (as I suspect it probably is), >>> would it be technically feasible to implement a cheaper "upgrade" that >>> converts the previous code cache to the current one? It's not ideal, but >>> it >>> could significantly reduce the costs needed to upgrade many scripts at >>> once >>> >>> I suspect that any improvement here would also apply to Chrome in the >>> form of a more consistent performance experience after an upgrade. >>> >>> We do have a fallback plan that's workable within the current >>> architecture, but it's got some downsides that would be neat to bypass by >>> stabilizing the format. Appreciate any feedback/insights anyone can offer. >>> >>> Thanks, >>> Vitali >>> >>> -- >> >> -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/CAKSzg3Qk%3D4y66misYkQjDnVZvzDiN2ZPKNd5XeHXeNYVELcOCQ%40mail.gmail.com.
