Open Bug 1892253 Opened 5 months ago Updated 1 month ago

Use a shared string buffer type for JS and DOM strings

Categories

(Core :: JavaScript Engine, task, P2)

task

Tracking

()

People

(Reporter: jandem, Unassigned)

References

(Depends on 2 open bugs, Blocks 2 open bugs)

Details

(Whiteboard: [sp3][js-perf-next])

We have an optimization to avoid copying for strings passed from the DOM to JS (external JS strings), but strings passed from JS to DOM bindings are usually inflated/copied. This copying can have significant performance and memory overhead.

At our work week we discussed some ideas to address this. For longer JS strings, the idea is to use a refcounted string-buffer type (nsStringBuffer or similar) that's shared with DOM strings. The JS string then holds a reference to this buffer and releases it in its finalizer. This is similar to how external strings work today but applied in a more general way. Shorter strings such as inline strings would still be copied.

Initially we'd still inflate Latin1 strings passed from JS code, but DOM bindings could be converted incrementally to work with Latin1 buffers directly.

This string buffer type could also be used for script sources and the SharedImmutableStringsCache.

We need to be careful with strings with nursery-allocated characters and mutability (JS strings are immutable, XPCOM string buffers can be mutated).

Depends on: 1892257
Severity: -- → N/A
Priority: -- → P2
Whiteboard: [sp3]
Depends on: 1896879
Depends on: 1899160
Depends on: 1903037
Depends on: 1904328
Depends on: 1904333
Depends on: 1905117
Depends on: 1906312
Depends on: 1906848
Depends on: 1907891
Depends on: 1908395
Depends on: 1909890
Depends on: 1910084
Depends on: 1910544
See Also: → 1375565
Depends on: 1914378

js-perf-next: Finish up any remaining worthwhile work on the SM side. Find someone who can take advantage of this on the DOM side.

Whiteboard: [sp3] → [sp3][js-perf-next]
You need to log in before you can comment on or make changes to this bug.