Deserializzazione Zero-Garbage String in Java, problema oggetto Humongous

Question

Sto cercando un modo per deserializzare uno String da un byte[] in Java con il minor numero di rifiuti possibile. Poiché sto creando il mio serializzatore e il de-serializzatore, ho la completa libertà di implementare qualsiasi soluzione sul lato server (ad esempio durante la serializzazione dei dati) e sul lato client (ad esempio, quando la serializzazione dei dati).

sono riuscito efficientemente serializzare un String senza incorrere in alcun overhead immondizia scorrendo le String's caratteri (String.charAt(i)) e convertendo ogni char (valore a 16-bit) a 2x valore a 8 bit. C'è un bel dibattito su questo here. Un'alternativa è utilizzare Reflection per accedere direttamente allo char[], ma questo non rientra nell'ambito del problema.

Tuttavia, sembra impossibile per me deserializzare il byte[] senza creare il char[]due volte, che sembra, beh, strano.

La procedura:

1. Creare char[]
2. Scorrere byte[] e compilare il char[]
3. Crea String con String(char[]) costruttore

A causa di String regole immutabilità di Java, il costruttore copia il carattere [], creando 2x overhead GC. Posso sempre usare i meccanismi per eludere questo (allocazione non sicura String + Reflection per impostare l'istanza char[]), ma volevo solo chiedere se ci sono delle conseguenze su questo diverso da me che infrange ogni convenzione sull'immutabilità String's.

Naturalmente, la risposta più saggia a questo sarebbe "dai, smetti di fare questo e abbi fiducia in GC, l'originale char[] sarà estremamente breve e G1 se ne libererà momentaneamente", che in realtà ha senso , se lo char[] è inferiore a 1/2 della dimensione della regione del G1. Se è più grande, il carattere [] verrà assegnato direttamente come oggetto gigantesco (cioè propagato automaticamente al di fuori della regione del G1). Tali oggetti sono estremamente difficili da raccogliere in modo efficiente in G1. Ecco perché ogni assegnazione è importante.

Qualche idea su come affrontare il problema?

Molte grazie.

Answer 1

Ho trovato una soluzione, che è inutile, se si dispone di un ambiente non gestito.

La classe ha un costruttore pacchetto-privato String(char[] value, boolean share).

Fonte:

/* 
* Package private constructor which shares value array for speed. 
* this constructor is always expected to be called with share==true. 
* a separate constructor is needed because we already have a public 
* String(char[]) constructor that makes a copy of the given char[]. 
*/ 
String(char[] value, boolean share) { 
    // assert share : "unshared not supported"; 
    this.value = value; 
} 

Questo è stato ampiamente utilizzato all'interno di Java, per esempio in Integer.toString(), Long.toString(), String.concat(String), String.replace(char, char), String.valueOf(char).

La soluzione (o hack, qualsiasi cosa si voglia chiamare) è spostare la classe nel pacchetto java.lang e accedere al costruttore pacchetto-privato. Questo non sarà di buon auspicio per il responsabile della sicurezza, ma questo può essere aggirato.

Answer 2

Tali oggetti sono estremamente difficili da raccogliere in modo efficiente in G1.

Questo potrebbe non essere più vero, ma sarà necessario valutarlo per la propria applicazione. Gli errori JDK 8027959 e 8048179 introducono nuovi meccanismi per la raccolta di oggetti voluminosi e di breve durata. In base alle flag di errore potrebbe essere necessario eseguire le versioni jdk ≥8u40 e ≥8u60 per sfruttare i rispettivi vantaggi.

opzione Sperimentale di interesse:

-XX:+G1ReclaimDeadHumongousObjectsAtYoungGC 

Tracing:

-XX:+G1TraceReclaimDeadHumongousObjectsAtYoungGC 

Per ulteriori consigli e le domande per quanto riguarda quelle caratteristiche mi sento di raccomandare che colpisce il hotspot-gc-use mailing list.