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 <vlov...@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/CAF8PYMgNXRdvW16Sb%3DwRaU21XGcMG3eBgkz_ey65%2BX7DdQ0a6g%40mail.gmail.com > <https://groups.google.com/d/msgid/v8-users/CAF8PYMgNXRdvW16Sb%3DwRaU21XGcMG3eBgkz_ey65%2BX7DdQ0a6g%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- -- 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/CAKKwF6Nprma4qd_orq-WBZ4%2BuibWYpRdEo9pTonGfnVfuAp1cw%40mail.gmail.com.
