Este incidente revela una regresión de rendimiento insidiosa causada por un cambio de alineación de código que, aunque no modificó la lógica de una ruta caliente, alteró su mapeo en la caché de instrucciones L1 (L1i). La causa raíz fue un aumento significativo en los 'L1i conflict misses' debido a la limitada asociatividad de la caché. La L1i, siendo de 32KB y 8-way set associative (64 sets x 8 ways x 64-byte cachelines), no pudo acomodar múltiples rutas de código caliente que, debido al desplazamiento de alineación, empezaron a competir por los mismos sets de caché.
El cambio en una función (createBackwardReferences en hash2.go) redujo su tamaño, lo que provocó que el compilador Go reubicara el código de funciones posteriores (como hash2u16.go) en la memoria. Este desplazamiento de 416 bytes (un múltiplo de 32) fue suficiente para que las instrucciones críticas de hash2u16.go y otras funciones 'peer' (como huffmanBlock.writeData, encodeState.reset) comenzaran a mapear a los mismos sets de caché L1i. Aunque la L1i es 8-way associative, la presencia de 9 o más cachelines calientes compitiendo por un mismo set provocó evicciones constantes, triplicando los misses de L1i y duplicando los stalls de la caché.
Las salvaguardas tradicionales fallaron porque la regresión no fue un error lógico ni un aumento en el número de instrucciones, sino un problema de interacción de bajo nivel entre el código y la arquitectura de la CPU. Las métricas de rendimiento generales mostraron la regresión, pero solo un análisis profundo con 'perf' (especialmente con eventos como L1i-misses y PEBS) y scripts personalizados para mapear la ocupación de sets de caché pudo identificar la causa raíz. La naturaleza transitoria del problema (dependiente de la alineación) hace que las soluciones permanentes sean difíciles de implementar a nivel de código de aplicación, ya que cualquier cambio futuro podría reintroducir el problema.