1604121 - Rewrite and optimize source notes

Status: NEW

(Core :: JavaScript Engine, task, P2)

Description

[Jan de Mooij [:jandem]]

The past weeks a ton of source notes have been removed. The remaining ones are:

• SRC_ASSIGNOP: hint for expression decompiler.
• SRC_TRY: hint for JIT bytecode analysis and IonBuilder. This should probably be a JSOP_TRY bytecode operand instead.
• SRC_NEWLINE/SRC_SETLINE/SRC_COLSPAN: line/column data
• SRC_BREAKPOINT/SRC_STEP_SEP: debugger hints

Source notes use quite a bit of memory, enough to trigger Treeherder notifications when we removed a number of source notes recently. I think it's worth doing measurements to verify this and then figure out if/how we can encode source notes more efficiently.

Here are some ideas:

1. We should find a more compact encoding. If we support binary search, we avoid O(n) lookups and will fix bug 929950 in the process. One option is making this a two-step process: first do a binary search to find an approximate offset and then read up to N 'notes' out of a more compact buffer.

2. Because there's so much line/column (and debugger?) data, it might make sense to store it separately from other source notes to allow a more compact encoding.

3. Line/column numbers should be relative to script->lineno()/script->column(). This is more compact and allows more SharedScriptData sharing for similar functions at different source locations.

4. The debugger breakpoint/stepping data would ideally only be generated when we need it. This could be stored in a separate SharedScriptData => DebuggerInfo map. Maybe once bytecode generation is more pure we could do this more easily.

Comment 1

[Jan de Mooij [:jandem]]

(In reply to Jan de Mooij [:jandem] from comment #0)

If we support binary search, we avoid O(n) lookups and will fix bug 929950 in the process. One option is making this a two-step process: first do a binary search to find an approximate offset and then read up to N 'notes' out of a more compact buffer.

This may also let us remove JSOP_LINENO and GSNCache. These are workarounds for source notes being susceptible to O(n²) behavior, but that still happens in practice (bug 929950 has some examples).

Comment 2

[Tooru Fujisawa [:arai]]

The remaining source note types are the following:

• Null
• AssignOp
• ColSpan
• NewLine
• SetLine
• Breakpoint
• StepSep
• XDelta

Null can be omitted if we always use length for detecing the end of vector,
Most remaining types are either line/column or debugger, except for AssignOp.

Maybe AssignOp can be moved to no-op opcode to further compress the note, or introduce compound type (bug 1849287)