gioser

sergio/takana

> Una distribución Linux construida con un laboratorio funcional y hermético en el > sótano, y una terminal mutable, clásica y anárquica en el piso de arriba — diseñada > desde el suelo para que una IA programadora entienda, modifique y co…

TOML 1173Shell 64Rust 62Markdown 441482 Sutichaykuna

jarlog: la mitad del PGO que faltaba — el orden de omni.ja para el arranque

El jarlog registra en qué orden se LEEN los ficheros dentro de omni.ja al
arrancar; con él, el empaquetador los reordena y el arranque hace lecturas
secuenciales en vez de saltar por el archivo.

NO hizo falta la extensión Quitter de Mozilla, que era lo que yo daba por
bloqueante: basta MOZ_JAR_LOG_FILE en el entorno del navegador. Su
profileserver.py sólo traduce JARLOG_FILE a esa variable — leerlo costó un grep
y ahorró rehacer el arnés entero.

Y se genera en una corrida APARTE, que está medido y no supuesto. Mozilla lo
emite en la misma sesión del profileserver; nuestro arnés arranca un navegador
POR PÁGINA, así que había que saber si el fichero se acumula o se pisa. Se pisa:
tras rejilla.html y tras tablas.html dio exactamente los mismos 27.652 bytes y
469 líneas. Su contenido lo domina el ARRANQUE, no la página, así que una
corrida dedicada vale igual que una de 46 — rehacer el perfilado sólo para
obtenerlo habría sido gasto sin diferencia. Se conserva el profdata ya medido
(el del -11,4%), que es lo que hace comparables los números.

Guardián propio: un jarlog vacío o que no nombre los archivos reales NO rompe el
build de firefox, sólo deja el omni.ja sin ordenar — o sea que se pierde justo
lo que se vino a buscar, en silencio. Se exige que mencione los DOS archivos que
el navegador abre (omni.ja y browser/omni.ja).

d9833a581b5763903b121cfe87b88a2a5dde0c89 · ruwaq Sergio · (1 killa ñawpaq) · tayta b00d513fb · kay commitpi sach'ata qhaway

Semántico sayk'uy

Mana ima sutichaypas t'ikrakurqanchu: qillqalla, yachachiylla utaq willaylla t'ikrakurqan.

2 qillqakuna · +32 −9

diff --git a/recipes/firefox-pgo-profile.toml b/recipes/firefox-pgo-profile.toml
index 2459cdbd..1b128b9b 100644
--- a/recipes/firefox-pgo-profile.toml
+++ b/recipes/firefox-pgo-profile.toml
@@ -14,7 +14,16 @@
 # a punta: flexbox, grid, tablas, texto en columnas, selectores, pintado, transforms, SVG, scroll
 # pegajoso y layout thrashing. Efecto medido en el propio perfil: las ejecuciones registradas pasan
 # de 5.885.254.799 a 38.498.366.335 (**6,5×**).
-# `firefox` lo consume con `--enable-profile-use=cross`.
+# Y desde 2026-09-08 también el **`jarlog`**: el orden en que se leen los ficheros dentro de
+# `omni.ja` al arrancar, para que el empaquetador los reordene y el arranque lea secuencialmente.
+# `firefox` los consume con `--enable-profile-use=cross` y `--with-pgo-jarlog`.
+#
+# ⚠ EL JARLOG SE GENERA EN UNA CORRIDA APARTE, Y ESO ESTÁ MEDIDO, NO SUPUESTO. Mozilla lo emite en
+# la misma sesión del `profileserver.py`; acá el arnés arranca un navegador POR PÁGINA, así que
+# había que saber si el fichero se acumula o se pisa. Se pisa: tras `rejilla.html` y tras
+# `tablas.html` dio **exactamente los mismos 27.652 bytes y 469 líneas**. O sea que su contenido lo
+# domina el ARRANQUE y no la página, y por eso una corrida dedicada vale igual que una de 46 —
+# rehacer el perfilado entero sólo para obtenerlo habría sido gasto sin diferencia.
 #
 # ══ POR QUÉ ES UNA FUENTE PINEADA Y NO UNA RECETA QUE LO GENERA ════════════════════════════════
 # **El perfil NO ES DETERMINISTA**: los contadores dependen del timing de la corrida, así que dos
@@ -42,12 +51,12 @@
 # aplican por nombre de función— pero vale menos: las funciones que ya no existen se ignoran y las
 # nuevas quedan sin datos. Regenerarlo es su propia unidad de trabajo, no un efecto secundario.
 name    = "firefox-pgo-profile"
-version = "2026.09.08"
+version = "2026.09.08b"
 license = "MPL-2.0"
 
 [source]
-tarball = "https://no-hay-upstream.invalid/hammer/firefox-pgo-2026-09-08.tar.xz"
-sha256  = "95472411ba252e14c4d57de7193d53e4ba35fbccf4819ba95ceff1ca843e4a7a"
+tarball = "https://no-hay-upstream.invalid/hammer/firefox-pgo-2026-09-08b.tar.xz"
+sha256  = "92497cddca82a3e92a6fbb80b8d78245543ed25418a11b681f4b28d890e3a1f0"
 # ⚠ `0` Y NO EL DEFAULT. hammer recorta UN componente al extraer, porque los releases GNU vienen
 # con un `proyecto-version/` de más. Este tarball es nuestro y lleva el fichero en la raíz, así que
 # con el default se recortaba lo único que hay y el install moría en `cp: cannot stat
@@ -64,6 +73,7 @@ install = '''
 set -e
 mkdir -p /out/usr/share/firefox-pgo
 cp merged.profdata /out/usr/share/firefox-pgo/merged.profdata
+cp jarlog          /out/usr/share/firefox-pgo/jarlog
 
 P=/out/usr/share/firefox-pgo/merged.profdata
 
@@ -80,4 +90,18 @@ test "$n" -gt 100000 || {
   exit 1
 }
 echo "guardián: perfil válido — $n funciones, $(stat -c%s "$P") bytes"
+
+# ── GUARDIÁN DEL JARLOG ──────────────────────────────────────────────────────────────────────
+# El jarlog es el orden en que se LEEN los ficheros dentro de `omni.ja` al arrancar; con él, el
+# empaquetador los reordena para que el arranque haga lecturas secuenciales. Un jarlog vacío o que
+# no nombre los archivos reales no rompe el build de firefox — sólo deja el `omni.ja` sin ordenar,
+# o sea que se pierde justo lo que se vino a buscar, en silencio. Se exige que nombre los DOS
+# archivos que el navegador abre.
+J=/out/usr/share/firefox-pgo/jarlog
+test -s "$J" || { echo "!! el jarlog está vacío o no existe" >&2; exit 1; }
+for a in omni.ja browser/omni.ja; do
+  grep -q "^$a " "$J" || { echo "!! el jarlog no menciona '$a' — ¿se generó sin arrancar el navegador?" >&2
+    awk '{print $1}' "$J" | sort -u | head -5 >&2; exit 1; }
+done
+echo "guardián: jarlog con $(wc -l < "$J") entradas sobre omni.ja y browser/omni.ja"
 '''
diff --git a/recipes/firefox.toml b/recipes/firefox.toml
index 4766c7e6..0d3bf048 100644
--- a/recipes/firefox.toml
+++ b/recipes/firefox.toml
@@ -255,6 +255,7 @@ ac_add_options --disable-install-strip
 ac_add_options --disable-cargo-incremental
 ac_add_options --enable-profile-use=cross
 ac_add_options --with-pgo-profile-path=/usr/share/firefox-pgo/merged.profdata
+ac_add_options --with-pgo-jarlog=/usr/share/firefox-pgo/jarlog
 ac_add_options --with-wasi-sysroot=/usr/share/wasi-sysroot
 ac_add_options --enable-alsa
 ac_add_options --enable-pulseaudio
@@ -473,10 +474,8 @@ build = [
   # que se recalcule: ver la cabecera de `recipes/firefox-pgo-profile.toml` para por qué un perfil
   # generado en cada build rompería la reproducibilidad en vez de darla.
   #
-  # ⚠ SIN `--with-pgo-jarlog`, Y ES UNA MITAD QUE FALTA, NO UN OLVIDO. Alpine pasa además un
-  # `jarlog` que reordena `omni.ja` para acelerar el ARRANQUE. Ese fichero lo emite el
-  # `profileserver.py` de Mozilla usando su extensión `Quitter`, que nuestra corrida headless no
-  # tiene. O sea que hoy se gana la disposición de CÓDIGO y no el orden del `omni.ja`. Es su propia
-  # unidad de trabajo y está escrito para que nadie lo lea como «PGO completo».
+  # ✅ CON `--with-pgo-jarlog` desde 2026-09-08: además de la disposición de CÓDIGO se ordena el
+  # `omni.ja` para el arranque, que era la mitad que faltaba. No hizo falta la extensión `Quitter`
+  # de Mozilla: basta con `MOZ_JAR_LOG_FILE` en el entorno del navegador.
   "firefox-pgo-profile",
 ]