(Desarrollador V8 aquí.)

V8 construye un marco de pila diferente para cada tipo de objeto de código. Significa que V8 debe conocer el tipo de destinatario antes de ejecutarlo.

Los marcos de pila los configura quien los necesita, por lo que las personas que llaman no tienen que inspeccionar a los destinatarios de las llamadas. (Podrían, si tuvieran que hacerlo).

Si el código de la máquina se ejecuta directamente en el procesador, nada puede ayudar a V8 a determinar el tipo de destinatario.

V8 podría emitir un código de máquina que verifica el tipo de destinatario. Pero para repetirme: no es necesario conocer el estado de optimización de un destinatario.

¿V8 supervisa la ejecución del código de máquina (optimizado)?

No, no lo hace.

¿Cómo comprueba V8 la invalidación de la dependencia del código?

Las dependencias se instalan en algo que puede cambiar (por ejemplo, mapas, protectores). Cuando ocurra ese cambio, las dependencias del código registrado se desoptimizarán (es decir, se marcarán como "desoptimización perezosa" cuando tengan activaciones en la pila, o simplemente se descartarán de lo contrario).

[¿Cómo detecta V8] si el destinatario está compilado o no?

No es necesario. Cuando una función aún no está compilada, su "código" será un código auxiliar que activa la compilación.

Para ver el ejemplo concreto que diste en los comentarios:

 var b = false; function change_o() { // as long as b is false, this won't be reassigned ... if (b) o = { y : 1, x : 0}; } var o = { x : 1 }; function f() { change_o(); // ... and thus ox can be compiled down return ox; } // f and change_o are compiled somewhen f(); f(); f(); // ... // a precondition changes b = true; // during execution of change_o o is reassigned and changes its shape, accessing ox will now need a different offset and thus f (which is currently on the stack) becomes invalid f();

Por lo tanto, en el momento en que ocurre la asignación o = , el tiempo de ejecución salta a alguna lógica de desoptimización, que tiene que invalidar todo el código en función de la suposición falsa. Invalidar llamadas de código no compilado a código compilado es fácil, simplemente elimine la referencia al código compilado de algún tipo de registro y nadie volverá a llamarlo. Invalidar llamadas futuras de funciones compiladas a la función compilada invalidada es más difícil, aunque si la llamada utiliza alguna indirección, esta indirección se puede reescribir para redirigir todas las llamadas futuras. Esto deja dos tipos de problemas de invalidación:

• la función evaluada actualmente debe ser invalidada (-> desoptimización ansiosa), tampoco es tan problemático ya que es la función que rescató a la rutina de desoptimización
• una función que llamó a la función evaluada debe ser invalidada (-> desoptimización diferida), esto es problemático, ya que podría estar en algún lugar de la pila, y la ejecución continua se reanudaría en algún momento (por ejemplo, f en el ejemplo anterior)

Sin embargo, en el último caso, hay una manera de encontrar y reemplazar esas funciones: cada vez que una función call a otra, empuja la dirección de retorno a la pila (ver, por ejemplo, el uso de la pila x86 ), y cuando la función llamada ejecuta el ret instrucción, aparece la dirección y salta allí. Por lo tanto, al escanear la pila en busca de direcciones de retorno que residen dentro de funciones invalidadas y reemplazarlas por otra dirección, cuando la función interna como change_o regresa a f , en realidad no salta de regreso al código f compilado sino a un controlador, que luego puede hacer los ajustes necesarios.

Entonces V8 no "supervisa" la ejecución, la modifica activamente cuando es necesario reescribiendo la pila.

Puede encontrar un tutorial detallado aquí .