Sergio
e74d449655
Estaba en un scratchpad y se perdía; ahora vive en el repo con el porqué de cada guarda, porque las tres se pagaron durante la primera corrida: 1. --unshare-pid en el bwrap. Sin él los hijos SOBREVIVEN al sandbox: un http.server quedó vivo 19 HORAS, retuvo el puerto y envenenó las corridas siguientes con «Address in use». 2. Puerto aleatorio por corrida. Elimina la colisión de raíz en vez de detectarla: si otro proceso tiene un puerto, este arranque usa otro. 3. Marcador único por corrida, servido desde una copia ESCRIBIBLE del corpus. La versión anterior horneaba el marcador como constante del script, y eso rompía justo lo que el chequeo existe para probar: el servidor huérfano servía el MISMO fichero de marca y el chequeo lo daba por bueno. Verificaba «alguien sirve este contenido», no «este servidor es el mío». Con el marcador por corrida, un servidor ajeno devuelve otra cosa y se aborta. Y queda escrito por qué los sandboxes de Firefox van apagados en el entrenamiento: con ellos los hijos mueren con signal 11, el proceso que renderiza no nace, el servidor registra 0 GET y el único .profraw es el del padre arrancando — un perfil de nada, con todo en verde. Es lo que hace el profileserver.py de Mozilla. Sólo aplica al entrenamiento. La espera al servidor va con reintento y no con un sleep fijo: 2 s concluían «no responde» sobre uno que sí iba a responder.
Corpus de maquetación para el PGO de Gecko
Páginas de entrenamiento nuestras que complementan el corpus de Mozilla (build/pgo).
Por qué existe
Medida la ganancia del PGO el 2026-09-07 (SDD 26 §3.a): −9,4 % en una página de DOM/maquetación
y −1,0 % en 3d-raytrace de SunSpider. El corpus de Mozilla está dominado en número de páginas
por SunSpider, que es aritmética pura en bucles calientes — y ese bucle no lo ejecuta el C++ de
SpiderMonkey sino el código máquina que el JIT emite en runtime, que el PGO no toca. O sea que el
corpus entrenaba mucho justo donde el PGO menos rinde.
Estas páginas ejercitan el camino que sí es C++ de punta a punta: resolución de estilo, layout, pintado y composición.
Reglas que cumplen todas, y por qué
- Deterministas. Ni
Math.randomniDateni red. Dos corridas hacen LO MISMO, así que dos perfiles difieren por el timing de los contadores y no por haber visitado caminos distintos. - Autocontenidas. CSS y JS en línea, sin recursos externos. El perfilado corre sin red.
- Nuestras. Escritas para esto: nada de páginas ajenas capturadas, que traerían licencia y fragilidad.
- Acotadas. Cada una termina en segundos. El perfilado arranca un navegador POR PÁGINA.
Qué ejercita cada una
| página | subsistema |
|---|---|
flex.html |
flexbox anidado, wrap, alineaciones, min/max-content |
rejilla.html |
CSS Grid: muchas pistas, áreas nombradas, auto-fit, subgrid |
tablas.html |
tablas grandes, colspan/rowspan, table-layout fijo y automático |
texto.html |
texto largo, columnas, text-shadow, tamaños y pesos variados, reflujo |
selectores.html |
resolución de estilo: DOM profundo contra cientos de reglas |
pintado.html |
degradados, border-radius, box-shadow, opacity, mix-blend-mode |
transformar.html |
transform, contextos de apilamiento, will-change |
svg.html |
SVG en línea: paths, degradados, use, clip |
desbordes.html |
overflow anidado, position: sticky, scroll programático |
reflujo.html |
layout thrashing: leer y escribir geometría alternadamente |