Hack the JVM per evitare verifiche e cast inutili

Question

Esistono alcune lingue che supportano un sistema di tipi sufficientemente potente che possono dimostrare in fase di compilazione che il codice non indirizza una matrice al di fuori dei limiti. La mia domanda è che se dovessimo compilare un tale linguaggio per la JVM, c'è un modo in cui potremmo trarne vantaggio per le prestazioni e rimuovere i controlli dei limiti di array che si verificano su ogni accesso di array?

1) So che il recente JDK supporta l'eliminazione di un controllo associato all'array, ma poiché so che al momento della compilazione alcune chiamate sono sicure, posso rimuovere molto più sicuro.

2) Alcuni potrebbero pensare che questo non influisce molto sulle prestazioni, ma lo è sicuramente, soprattutto nelle applicazioni pesanti di array/computazione come il calcolo scientifico.

La stessa domanda per quanto riguarda il casting. So che qualcosa è un certo tipo, ma Java non lo fa perché il suo sistema di tipo limitato. C'è un modo per dire semplicemente alla JVM di "fidarsi di me" e saltare qualche assegno?

Mi rendo conto che probabilmente non c'è modo di farlo poiché la JVM è generalmente distribuita, potrebbe essere ragionevole modificare una JVM con questa funzione? È qualcosa che è stato fatto?

È una delle frustrazioni nella compilazione di un linguaggio più potente nella JVM, ma è ancora ostacolato dai limiti di Java.

Answer 1

In linea di principio questo non può essere fatto in modo sicuro senza un'infrastruttura proof-carrying code (PCC). PCC ti consentirebbe di incorporare il tuo ragionamento di sicurezza nel file class. La prova incorporata viene verificata in fase di caricamento della lezione. La classe non è caricata se c'è un difetto nella dimostrazione.

Se la JVM mai permesso di escludere i controlli runtime senza richiedere una prova formale, poi, come SecurityMatt dirla, sarebbe sconfiggere la filosofia originale di Java come piattaforma sicura.

La JVM utilizza un modulo speciale di PCC per il controllo del tipo di variabili locali in un metodo. Tutte le informazioni di digitazione della variabile locale vengono utilizzate dal meccanismo di caricamento della classe per verificarne la correttezza, ma dopo questo vengono eliminate.Ma questa è l'unica istanza di concetti PCC utilizzati nella JVM. Per quanto ne so, non esiste un'infrastruttura PCC generale per JVM.

una volta ho sentito uno esisteva per la piattaforma JavaCard che supporta un piccolo sottoinsieme di Java. Non sono sicuro che ciò possa essere d'aiuto nel tuo problema.

Answer 2

Una delle caratteristiche chiave di Java è che non è necessario "fidarsi" dello sviluppatore per eseguire il controllo dei limiti. Ciò elimina le vulnerabilità di sicurezza "buffer overflow" che possono portare gli hacker a eseguire codice arbitrario all'interno dell'applicazione.

Consentendo agli sviluppatori la possibilità di disattivare il controllo dei limiti, Java perderebbe una delle sue caratteristiche principali: non importa quanto sia sbagliato lo sviluppatore Java, non ci sarà alcun buffer overflow sfruttabile all'interno del suo codice.

Se si desidera utilizzare una lingua in cui il programmatore è considerato affidabile per gestire i propri limiti di controllo, potrei suggerire C++. Questo ti dà la possibilità di allocare array senza controllo automatico dei limiti (new int []) e di allocare gli array con il controllo dei limiti incorporati (std :: vector).

Inoltre, vi consiglio vivamente che, prima di incolpare i limiti di controllo per la perdita di velocità nell'applicazione, si eseguono alcuni BENCHMARKING per determinare se vi sia qualche altra parte nel codice che potrebbe essere la causa del collo di bottiglia.

Potresti scoprire che per un target del compilatore un linguaggio bytecode come MSIL è più adatto alle tue esigenze rispetto al bytecode Java. MSIL è fortemente digitato e non soffre di una serie di inefficienze che hai trovato in Java.