Solo 40 righe di codice: così OpenJDK rende la JVM fino a 400x più veloce

Java è da decenni una delle colonne portanti del software moderno. È utilizzato in ambito enterprise, finanziario, industriale e cloud, alimenta piattaforme di e-commerce, sistemi di pagamento, motori di ricerca, infrastrutture di streaming e una quantità enorme di servizi backend critici. Gran parte di questa diffusione non è dovuta solo al linguaggio in sé, ma alla Java Virtual Machine (JVM), che fornisce un ambiente di esecuzione maturo, altamente ottimizzato e progettato per funzionare in modo affidabile sotto carichi elevati e continuativi.

Oggi, quando si parla di Java in produzione, nella stragrande maggioranza dei casi si parla di JVM derivate da OpenJDK. OpenJDK è la base di riferimento per quasi tutte le configurazioni: dalle build ufficiali di Oracle alle versioni adottate dai principali cloud provider, fino alle JVM utilizzate nei container e nei microservizi. In altre parole, OpenJDK non è una variante marginale, ma lo standard de facto dell’ecosistema Java server-side.

Una scoperta inattesa che ha permesso di migliorare le prestazioni di JVM: da 30 a 400 volte

Scorrere i commit di grandi progetti open source è un esercizio che raramente regala sorprese clamorose, ma ogni tanto capita di imbattersi in una di quelle modifiche che fanno riflettere su quanto il design storico possa pesare sulle prestazioni. È esattamente ciò che è successo con una recente modifica al codice Linux di OpenJDK, capace di cancellare un gap prestazionale compreso tra 30× e 400× con una modifica minimale (40 righe di codice).

Come spiega l’autore dell’innovazione, il bersaglio del cambiamento è ThreadMXBean.getCurrentThreadUserTime(), un’API apparentemente innocua, ma che nascondeva una delle implementazioni più costose dell’intero sottosistema di monitoraggio dei thread in OpenJDK.

Parlando di Java, infatti, le prestazioni non si giocano più solo sull’esecuzione del codice applicativo. Sempre più spesso, il vero fattore discriminante è quanto costa osservare il sistema mentre svolge un certo carico di lavoro. Metriche, profiling continuo, diagnostica in produzione e analisi post-mortem sono diventati parte integrante del ciclo di vita di un servizio.

La modifica introdotta in OpenJDK riguarda il modo in cui la JVM misura il tempo CPU “user” del thread corrente. Un dettaglio apparentemente marginale, che però per anni ha avuto un costo sproporzionato.

Un costo occulto che cresceva con il sistema

Per lungo tempo, ottenere il tempo CPU di un thread su Linux significava attraversare un percorso complesso e costoso, basato sulla lettura e sul parsing di informazioni tratte dal file system virtuale /proc. L’approccio aveva una caratteristica subdola: il suo impatto aumentava proprio nei momenti in cui il sistema era più sotto stress.

Su istanze in cui la concorrenza tra thread è marginale, il problema rimaneva invisibile. Ma nei server moderni — microservizi, API ad alto throughput, pipeline di elaborazione eventi — la misurazione del tempo CPU avviene spesso ad ogni richiesta, per molti thread e in modo continuativo.

Il risultato era un effetto paradossale: più si cercava di capire cosa stesse succedendo sul sistema, più si contribuiva ad appesantirlo. Non di rado, parte della latenza e del carico sulla CPU  era ingenerato proprio dagli strumenti di monitoraggio.

Cosa cambia davvero con la nuova implementazione

Con la nuova implementazione introdotta in OpenJDK, il tempo CPU del thread è ottenuto tramite un’unica chiamata diretta al kernel, senza accessi a /proc, senza parsing e senza lavoro superfluo. Il costo passa da microsecondi a poche decine di nanosecondi.

Tradotto in termini pratici, questo significa che la misurazione diventa finalmente proporzionata all’informazione che fornisce. Non è più un’operazione “pesante” da usare con cautela, ma una lettura rapida, stabile e prevedibile.

I contesti in cui il beneficio è reale

I vantaggi emergono soprattutto sui sistemi Linux che eseguono JVM complete e aggiornate, tipicamente backend server, piattaforme cloud, ambienti containerizzati e infrastrutture di microservizi. In questi contesti, il tempo CPU per thread viene spesso usato indirettamente da framework di metriche, APM, strumenti di autoscaling o meccanismi di throttling.

In presenza di concorrenza elevata, la differenza è ancora più evidente. Prima, il costo della misurazione cresceva con il numero di thread e con il carico complessivo del sistema. Ora rimane sostanzialmente costante. Sparisce così una fonte di rumore che, in passato, poteva distorcere le analisi proprio nei momenti critici, come i picchi di traffico o gli incidenti in produzione.

Nei sistemi in cui l’osservabilità è sempre attiva — e oggi sono la norma, non l’eccezione — l’effetto cumulativo è significativo: meno overhead, meno jitter, dati più affidabili.

Dove invece non cambia nulla

È importante chiarire anche i limiti dell’ottimizzazione appena introdotta in OpenJDK e quindi nella JVM. L’intervento, ad esempio, non ha alcun impatto su Android. Nonostante Android utilizzi un kernel Linux, il runtime è ormai ART (Android RunTime), non OpenJDK, e le API di gestione dei thread tipiche di Java SE non sono disponibili.

Allo stesso modo, applicazioni batch, job offline o programmi che non raccolgono metriche a livello di thread difficilmente noteranno differenze misurabili. Qui il collo di bottiglia non era rilevante nemmeno prima del brillante intervento correttivo.