JCarrillo.AOT.Core 1.1.4

JCarrillo.AOT.Core: Infraestructura para Baja Latencia y Native AOT

Biblioteca de infraestructura de alto rendimiento diseñada específicamente para entornos restrictivos en .NET (como compilación Native AOT y sistemas con tolerancia crítica a la latencia de recolección de basura). Garantiza un perfil de cero asignaciones en el Heap (0 B Allocated) en las rutas calientes de ejecución de consultas y sincronización.

Directorio de Documentación

Para acceder a la arquitectura y especificaciones detalladas de cada módulo, consulte las siguientes guías del repositorio:

• Directorio General de Documentación: Índice principal de guías.
• ValueLINQ: Consultas Fluent: Especificación del motor de consultas.
• Colecciones Rentadas (Pooled Collections): Estructuras de datos para pila.
• Extensiones y Sincronización: Bloqueos de exclusión mutua y validadores de stack.

Módulos y Componentes de la Biblioteca

1. ValueLINQ: Consultas Fluent en Pila

Motor de consultas síncrono diseñado para entornos Native AOT.

• Abstracción en Stack: Sustituye delegados y lambdas tradicionales (Func<T, bool>) por estructuras genéricas que implementan interfaces específicas (IWhereDelegado, ISelectDelegado), facilitando al compilador el inlining del código del usuario directamente en el bucle de iteración.
• Motores Eager y Delay: Proporciona dos motores de procesamiento: el motor ansioso (ValueLINQStruct<T>, ValueLINQRefStruct<T>) respaldado por ValueLINQStateManager<T> y arenas de memoria, y el motor perezoso (ValueLINQDelayStruct<T, TEnumerator> en .NET 9+) que evalúa la canalización directamente sobre la pila. Ambos motores disponen de materializadores públicos (ToList, ToArray, ToListStandard, ToArrayStandard) que aseguran la liberación determinista de recursos en bloques finally.
• Gestión de Estados y Arenas: En el motor eager, administra buffers en tablas particionadas por (tipo T, arena) con asignación en $O(1)$, aislamiento multihilo mediante SpinLock por ranura y reciclaje automático de tablas en pool para eliminar asignaciones en heap (0 B medido en régimen estacionario).
• Devolución Segura: Todos los operadores están encapsulados en bloques try-finally que aseguran la devolución automática de los buffers al ArrayPool en caso de excepciones durante la iteración.

2. Colecciones Rentadas (Pooled Collections)

Estructuras optimizadas para mitigar la presión sobre el recolector de basura (GC) mediante el reciclaje de memoria física.

• PooledList<T> y PooledArray<T>: Colecciones de tipo record struct que administran buffers del pool de arrays e integran validación dinámica de boxing en su método Dispose().
• PooledListRef<T> y PooledArrayRef<T>: Variantes ref struct confinadas a la pila por diseño de compilador, omitiendo validaciones en ejecución y logrando un rendimiento superior de entre el 18% y 32% (medido) en CPU.

3. Extensiones: SemaphoreLock y Detección de Boxing

Utilidades de diagnóstico de bajo nivel y primitivas de exclusión mutua de alta velocidad.

• SemaphoreLock: Estructura en pila que envuelve SemaphoreSlim permitiendo ámbitos using var seguros. Cuenta con una ruta rápida (Fast-Path) con Wait(0) que elude la asignación de la máquina de estados del compilador, y una ruta lenta optimizada con PoolingAsyncValueTaskMethodBuilder para reciclar tareas.
• Detección de Boxing: BoxingExtensions.ValidarNoBoxeado valida en tiempo de ejecución que el struct reside en los límites físicos de la pila de memoria del hilo actual (mediante P/Invoke a GetCurrentThreadStackLimits de kernel32.dll en Windows), lanzando una excepción si detecta que la estructura se encuentra en el heap.

Resultados de Benchmarks

• Entorno: Windows 11, CPU AMD Ryzen 9 3950X, .NET SDK 10.0.301, runtime .NET 10.0.9 (medido).
• Harness: BenchmarkDotNet v0.15.8, compilación en modo Release.

1. Desempeño en Native AOT 10.0 (Consultas Fluent a escala $N = 1000$)

En la prueba Where_Select (filtrar y proyectar en cadena), la resolución dinámica de interfaces de LINQ estándar sufre una regresión de rendimiento en .NET 10.0. ValueLINQ, al estar resuelto de forma estática en compilación, mantiene un perfil de latencia estable:

• Standard LINQ: 11,946.24 ns (11.9 µs) (medido) | Heap Allocated: 144 B (medido)
• ValueLINQStruct: 1,522.53 ns (1.5 µs) (medido) | Heap Allocated: 0 B (medido) (7.84x más rápido)
• ValueLINQRefStruct: 1,504.89 ns (1.5 µs) (medido) | Heap Allocated: 0 B (medido) (7.93x más rápido)
• ValueLINQDelay (net9+): 626.07 ns (0.6 µs) (medido) | Heap Allocated: 0 B (medido) (23.07x más rápido)

2. Población en Bloque vs Inserción Unitaria ($N = 1000$)

Comparativa entre la población iterativa (que adquiere $O(N)$ locks) y la población en bloque (Añadir(ReadOnlySpan<T>) que ejecuta un único lock $O(1)$ con copia vectorial):

• ValueLINQStruct (Población Unitaria): 32,838.03 ns (medido) | Heap: 0 B (medido)
• ValueLINQStruct (Población en Bloque): 178.29 ns (medido) | Heap: 0 B (medido) (184x más rápido)
• List<int> (Población en Bloque): 231.76 ns (medido) | Heap: 4,056 B (medido) (ValueLINQ es 35% más rápido y sin allocations)

Metodología de Desarrollo

Este proyecto se desarrolla en pareja humano-IA con roles definidos y verificación cruzada:

• Diseño y arquitectura: humanos. Cada decisión estructural (sistema de tokens generacionales, particionado de tablas, modelo de concurrencia, contratos de API) se origina y aprueba por el mantenedor.
• Implementación: mixta. El código de producción se escribe principalmente a mano; la IA implementa piezas concretas bajo especificación y revisión del mantenedor.
• Verificación adversarial: los tests, las revisiones de concurrencia y la documentación se elaboran con asistencia de IA instruida para refutar el código, no para confirmarlo.
• Regla invariante: ninguna contribución — humana o asistida — se integra sin pasar la suite completa en los tres target frameworks (net8.0/net9.0/net10.0). Las cifras de rendimiento publicadas se miden con BenchmarkDotNet; nunca se estiman.