Domanda sui tipi di valore proposti da Java

Question

Domanda sui tipi di valore proposti da Java

#1 da (4 voti)
#2 da (1 voti)

4

Sto leggendo la proposta del progetto Valhalla per aggiungere tipi di valore a Java . Sta discutendo per tipi di valori espliciti perché il compilatore non può spostare automaticamente le allocazioni dall'heap allo stack molto bene anche se gli oggetti sono immutabili (tutti i campi sono definitivi) perché non può sapere se un codice non verificherà improvvisamente il codice oggetto per l'uguaglianza di riferimento o prova a bloccarlo. L'identità dell'oggetto deve essere preservata e con essa l'allocazione dell'heap, la garbage collection e un carico di overhead per gli oggetti di piccole dimensioni che vengono allocati in cicli stretti.

La mia domanda è: perché l'identità dell'oggetto non può essere preservata nello stack? Voglio dire, rilasciare a ciascun oggetto un ID univoco e usarlo come sua identità invece del suo indirizzo. Gli oggetti immutabili possono quindi essere sempre passati per valore e mai raccolti.

Sembra una soluzione molto più semplice e più gradevole dei tipi di valore, anche se alcuni oggetti crescono di altri 8-12 byte. Ho usato C #, e i tipi di valore espliciti sono un dolore. Aggiungono un sacco di senso concettuale a una lingua.

java

posta Aleksandr Dubinsky 06.04.2016 - 22:14

fonte

2 risposte

Leggi altre domande sui tag java

C'è qualcosa da dire per mettere il caso "predefinito" di un'istruzione switch prima? Come progettare una collezione iterabile ma immutabile (di sola lettura)

score 4 · Answer 1

L'allocazione dello stack non è il motivo per cui viene presentata questa proposta. Stai fissando un vantaggio minore tra una lunga lista di quelli più sostanziali. La soluzione alternativa ha un lotto di sovraccarico, soprattutto quando alcuni degli obiettivi principali della proposta sono l'eliminazione del sovraccarico di spazio di un'intestazione di oggetto (da 8 a 16 byte) e un riferimento (da 4 a 8 byte ) e l'overhead temporale della dereferenziazione puntatore, quando non sono necessari staticamente.

Per quanto riguarda la capacità di determinare lo stack rispetto all'allocazione dell'heap, probabilmente non sei così bravo a predirlo per i tipi di riferimento come pensi di essere, e questa è una buona cosa. A nessuno importa dove sia allocata la loro memoria eccetto i programmatori C o C ++ e desiderano che non debbano preoccuparsene.

Tieni presente che la JVM è utilizzata da altri linguaggi, come Scala, che hanno già tipi di valore e utilizzano estensivamente i tipi immutabili e potrebbero davvero trarre vantaggio dall'ottimizzazione che il supporto JVM consentirebbe.

score 1 · Answer 2

La conservazione dell'identità nello stack può funzionare.

Tuttavia, l'ottimizzazione JIT risultante non sarà applicabile in modo così ampio come i tipi di valori reali. Ad esempio, i tipi di valore possono essere memorizzati (mediante inlining) come campi all'interno di oggetti, in matrici, ecc. Gli oggetti nello stack, nel frattempo, possono essere memorizzati solo all'interno di variabili locali di funzioni.

Tuttavia, se limitiamo l'ambito all'ottimizzazione di piccoli oggetti transitori (che si verificano in Java molto ), l'identità di conservazione non funziona. Tuttavia, le cose diventano un po 'pelose se ci troviamo a passare l'oggetto a un contesto che si aspetta un riferimento. Ad esempio, prova ad archiviarlo in un campo. Possiamo allocare un heap "double" e usare il suo indirizzo. Aggiungeremo questo indirizzo a una mappa. La prossima volta, cercheremo l'ID dell'oggetto nella mappa per ottenere l'indirizzo dello stesso heap doppio. In fase di GC, dovremo controllare i nostri oggetti allocati nello stack per sapere quali duplicati dell'heap possono essere liberati. Ciò che attenua questo costo è il fatto che il numero di variabili locali non è in genere elevato e, se ci troviamo a creare molti heap double, possiamo cambiare i metodi in modo da utilizzare oggetti allocati su heap.

Nel complesso, questa appare una ragionevole ottimizzazione rispetto al fatto di basarsi unicamente sull'analisi di fuga. Sarebbe interessante sapere perché, a conti fatti, il team della JIT ha deciso di non implementarlo.