¿Qué hay en realidad en los parches del kernel de la Initiative administrada y la JVM?

Question

http://managedruntime.org/ es bastante escaso en lo que son exactamente en los tarballs y por qué los usuarios los querrían. http://lwn.net/Articles/392307/ tiene más detalles, pero el autor tampoco está seguro de qué hacen realmente los módulos de gestión de memoria. Aparentemente, el objetivo de alto nivel es reducir las pausas de GC, pero me interesaría (apunta a) un resumen de lo que hace el módulo, y por qué/cómo eso mejora las cosas. Especialmente impresionante sería un indicador de algo sobre cuánto impacto tienen estos parches (una evaluación).

Answer 1

Azul's Pauseless GC se basa en el sistema de gestión de memoria del SO subyacente. en hardware Azul, esto fue llevado a cabo por el kernel personalizado de Azul (Aztec). En Linux, el sistema de administración de memoria debe ser capaz de admitir una cantidad suficiente de operaciones de administración de memoria por segundo para mantenerse al día con la cantidad de basura creada por segundo. Cuando la gente de Azul portó Azul JVM a Linux, determinaron que sus API de administración de memoria eran relativamente lentas en comparación con las de Aztec, aunque solo fuera porque las MM API de Linux nunca tenían la intención de soportar algo como PGC. los parches de MRT mejoran la cantidad de operaciones por segundo que el kernel de Linux puede manejar y, por lo tanto, son compatibles con PGC.

Una analogía sería la adición de poll/select a Berkeley Sockets, y más tarde, en 2001, cuando epoll se agregó al kernel de Linux (http://www.xmailserver.org/linux-patches/nio-improve.html).

[exención de responsabilidad: a pesar de que yo soy un ejecutivo de tecnología y asesor técnico actual o anterior a Azul, no hablo por ellos]