From d9833a581b5763903b121cfe87b88a2a5dde0c89 Mon Sep 17 00:00:00 2001 From: Sergio Date: Tue, 8 Sep 2026 02:16:53 +0000 Subject: [PATCH] =?UTF-8?q?jarlog:=20la=20mitad=20del=20PGO=20que=20faltab?= =?UTF-8?q?a=20=E2=80=94=20el=20orden=20de=20omni.ja=20para=20el=20arranqu?= =?UTF-8?q?e?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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). --- recipes/firefox-pgo-profile.toml | 32 ++++++++++++++++++++++++++++---- recipes/firefox.toml | 9 ++++----- 2 files changed, 32 insertions(+), 9 deletions(-) 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", ]