Interpreter frames are translated wrong in Node 8

[AndreasMadsen]

@mcollina asked me to share some details about interpreter frames.

When JavaScript functions aren't JIT compiled but interpreted the instruction addresses will point to the interpreter handlers and not compiled JavaScript frames directly. I have received the following information from V8 team member Jaroslav Sevcik on how this can be solved:

Also, as Benedikt points out, you will have trouble with interpreted functions because the instruction pointer points to the bytecode handler rather than to the actual JavaScript function. To get around this, you might want to use --log-code because that will log bytecode addresses, as well. When walking the stack, you could collect the bytecode array address as it lives in a fixed position in InterpreterEntryTrampoline's frames (see the SafeStackFrameIterator class, which is responsible for collecting the stacks for v8's builtin profiler). This could be later resolved using the --log-code log -- for InterpreterEntryTrampoline, you would simply interpret the bytecode array using the --log-code log.

[davidmarkclements]

so the problem is, correlating the addresses - they don't match in an obvious way – there's possibly variable offsets happening

on a side note, there's a way to ensure (hopefully almost) everything JIT compiles

0x -- node --always-opt app.js

This will show all functions in the flamegraph

[davidmarkclements]

I'm starting to think (for the second time in a year) that this is going to require patches to core,
for dtrace to the src/v8ustack.d file and for perf – I'm not sure where.

How else do we extract the bytecode array from within InterpreterEntryTrampoline frames..
If I'm understanding correctly (which I might not be quite probably am not) "InterpreterEntryTrampoline frames" as cited is a set piece of memory with offsets, we get those offsets from somewhere (from what I can see we've got 4096 byte chunks - pages, and then dynamic offsets within those). We have to be able to access that memory at tracing time, which means we have to modify the ustack helper (for dtrace, again for perf, no idea yet).

@AndreasMadsen @mcollina @mafintosh can you verify what I'm saying? Am I seeing this right?

[davidmarkclements]

yeah. now I remember: #76 (comment)

[AndreasMadsen]

For sure you can implement your own ustack helper, but that only solves the issue for SmartOS.

It might also be possible to implement your own ustack from scratch, in which case you will have MacOS covered too.

I don’t see any solution for linux pref, as that doesn’t allow runtime interruption execution, properly due to user space permission.

The current roadmap for V8, is to either:

• improve —pref
• add virtual frames for ByteCode frames
• teach Linux pref about ByteCode frames

See: nodejs/benchmarking#168

[davidmarkclements]

Also https://bugs.chromium.org/p/v8/issues/detail?id=7155

[davidmarkclements]

v4 mitigates this problem

[mmarchini]

FWIW there's an open CL on V8 (https://chromium-review.googlesource.com/c/v8/v8/+/959081) to make interpreted frames work nicely with external profilers. We're planning to have this shipped with Node.js 10.

How you're mitigating this problem on v4? I'd like to make sure these changes won't break it.

[davidmarkclements]

V4 uses the tick profiler - which has the frames (external tracing still supported with --kernel-tracing flag where it's still an issue)