1425524 - [meta] move frontend content process JS code to C++ or Rust where feasible

Status: RESOLVED INVALID

(Firefox :: General, enhancement, P5)

Description

[Nathan Froyd [:froydnj]]

Not sure if the bug title is super-accurate, but let's go with this for now.

JS code for content processes is inefficient from the memory point of view: we're paying the cost for JS source, JS objects, bytecode, JIT code, etc. in every single content process.  In contrast, putting similar code in C++ can get shared between all processes, and the C++ objects are...probably smaller than their equivalent JS objects?  Depends on a bunch of factors, I guess.

Anyway, this was an idea we came up talking about memory usage for content processes, and talking to Gijs indicated that it wasn't a completely off-base idea.  Filing a bug for people to comment and also for people to hang dependent work off of.

See bug 1425466 for similar, but related things.

Comment 1

[Alex Gaynor [:Alex_Gaynor]]

Is porting things to Rust, so we don't end up trading memory for vulnerabilities, an option? Or is that blocked on us having the infrastructure for Rust to directly implement/consume interfaces?

Comment 2

[Nathan Froyd [:froydnj]]

(In reply to Alex Gaynor [:Alex_Gaynor] from comment #1)
> Is porting things to Rust, so we don't end up trading memory for
> vulnerabilities, an option? Or is that blocked on us having the
> infrastructure for Rust to directly implement/consume interfaces?

This is an option.  We have the ability to implement XPIDL interfaces in Rust nowadays, so it doesn't even have to involve writing C++ shims for things.

Bug 1356594 comment 6 contains a useful caution about doing all of this.

Comment 3

[Eric Rahm [:erahm]]

Nathan, do you have a rough estimate of the overhead here?

Comment 4

[Andrew McCreight [:mccr8]]

(In reply to Eric Rahm [:erahm] (please no mozreview requests) from comment #3)
> Nathan, do you have a rough estimate of the overhead here?

I don't think that's a useful question, because it depends on the script, and each individual script would have to be ported separately. Chrome JS scripts can take anywhere from 60kb down to almost nothing. If we could magically port all chrome JS to Rust, maybe it would be megabytes of savings, but that doesn't feel very practical to me.

Comment 5

[Andrew McCreight [:mccr8]]

Just as a side note, from looking at logs, session store and telemetry stand out as two large uses of chrome JS script memory that seem like they'd be needed in every process. If the JS engine people come up with a way to share bytecode etc. memory across processes then this will be less of an issue.

Comment 6

[Nathan Froyd [:froydnj]]

(In reply to Eric Rahm [:erahm] (please no mozreview requests) from comment #3)
> Nathan, do you have a rough estimate of the overhead here?

What mccr8 said in comment 4.  kmag would have a better idea than me in any event.

(In reply to Andrew McCreight [:mccr8] from comment #5)
> Just as a side note, from looking at logs, session store and telemetry stand
> out as two large uses of chrome JS script memory that seem like they'd be
> needed in every process. If the JS engine people come up with a way to share
> bytecode etc. memory across processes then this will be less of an issue.

Session store would also gain significant efficiency from being written in C++, too.

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

The meta keyword is there, the bug doesn't depend on other bugs and there is no activity for 12 months.
:mossop, maybe it's time to close this bug?

Comment 8

[Dave Townsend [:mossop]]

I'm not sure that this bug really serves any purpose at this point.

Comment 9

[Andrew McCreight [:mccr8]]

Yeah, there has been work along these lines since this bug was filed, but the actual meta bug doesn't seem to have done any good.