replayio / chromium-v8 Goto Github PK

We currently emit record/replay bytecodes for all scripts in the main thread's isolate, including scripts which are ignored during instrumentation. We need to only emit these bytecodes for scripts which participate in instrumentation, to clean up the semantics of the bytecodes and support optimizing them in the JIT (#4).

See replayio/node#8

Currently we have a way to limit the recordings we're actually interested in remembering based on a filter of the URLs used for sources in the process. This has been awkward for our current use cases, and for now it would be better to allow filtering interesting recordings based on whether the process did any painting.

When unwinding an exception the record/replay driver is notified, and these notifications need to happen at consistent places when recording vs. replaying. Currently we notify the driver on all calls to Runtime_UnwindAndFindExceptionHandler, but we've been seeing problems where the number of calls to this method vary when unwinding a given exception. This is probably due to different JIT behavior. The driver only needs to be notified when the exception is first thrown, so we should be able to deal with this by using the progress counter to detect when the handler is being used to unwind additional frames, and not call the driver in such cases.

The record/replay bytecodes (RecordReplayIncExecutionProgressCounter and RecordReplayInstrumentation[Generator]) are always compiled into calls into the runtime. On the simple benchmark below this leads to a 20x overhead when recording (30ms) vs. not recording (700ms). On gecko, where we optimize these bytecodes, the overhead is much less (65ms vs 75ms). We need to optimize how these bytecodes are compiled to avoid degrading JS performance excessively.

function foo() {
  const arr = [];
  for (let i = 0; i < 2000000; i++) {
    arr.push(i);
    arr.push(i + 1);
    arr.push(i + 2);
    arr.push(i + 3);
    arr.pop();
    arr.pop();
    arr.pop();
  }
}

We need to associate IDs with each generator object in order to support async stepping. Currently we do this by storing an integer in JSGeneratorObject which is accessed when starting/resuming generators, but the modification this makes to js-generator.tq seems to be causing frequent scavenger crashes. We have a separate, slower weak map from objects to IDs which we can use instead and avoid modifying this tq file.