vm: eval cache mixes up script origins

Bug report

• Node.js: v24.19.0, v26.8.1, v27.0.0-pre (local build)
• Platform: Microsoft Windows NT 10.0.26200.0 x64
• Subsystem: vm

// test.mjs
import assert from 'node:assert/strict';
import { Script } from 'node:vm';

const out = [];

function createScript(name) {
  return new Script(`globalThis.eval('import("node:fs")')`, {
    importModuleDynamically(specifier) {
      out.push(name);
      return import(specifier);
    },
  });
}

const a = createScript('A');
const b = createScript('B');

for (const script of [a, b, a]) {
  await script.runInThisContext();
}

assert.deepEqual(out, ['A', 'B', 'A']);

Running this example as node --experimental-vm-modules test.mjs will give different wrong answers between v24 and v26 because V8 removed delayed caching some time during those releases. However, running with --no-compilation-cache will pass the test assertion.

The bug is with V8. In deps/v8/src/codegen/compiler.cc, around the "cache lookup key" comment, indirect eval uses kNoSourcePosition (-1), and the cache key does not distinguish the originating script. This allows identical eval source text from different scripts in the same realm to produce a false positive cache hit.

Riproduci il problema con il test.mjs fornito usando --experimental-vm-modules, quindi esamina deps/v8/src/codegen/compiler.cc intorno al commento "cache lookup key". Segui la ricerca nella cache di eval e i test correlati per capire come vengono rappresentate le origini degli script. Il lavoro è completato quando l’asserzione A/B/A passa con la cache della compilazione abilitata, mentre il comportamento esistente senza cache della compilazione rimane corretto.