Java Desktop System 2 di Sun: esce a Maggio
Sun ha annunciato che la seconda release di Java Desktop System sarà rilasciata il prossimo mese di maggio
di Fabio Boneschi pubblicata il 26 Aprile 2004, alle 15:06 nel canale Programmi








Qualcomm annuncia la nuova generazione di SoC Snapdragon 8 Elite Gen 6
realme 16 Pro Harry Potter Edition: il nuovo midrange ha uno stemma di Hogwarts che cambia colore al sole!
Recensione REDMI Note 17 Pro: il midrange con batteria da 8.340 mAh e ricarica veloce
OpenAI lancia GPT-6 Sol e Luna, dopo Astra: costi dimezzati e meno errori
Motorola annuncia Signature 27, uno dei primi smartphone con Snapdragon 8 Elite Extreme Gen 6
Ma Anthropic non doveva rallentare? Lanciato Opus 5.5: prestazioni al top, costi tagliati del 40%
La NASA conferma che due astronauti italiani cammineranno sulla Luna, accordo con l'ASI per il modulo MPH
Rockstar introduce regole stringenti per i modder: GTA 6 sarà molto meno tollerante
Big Fish, in Sicilia il più grande impianto agrivoltaico d'Italia: 227 MW su 400 ettari
Dongfeng mostra la piattaforma T1 in Europa: il futuro del trasporto su ruota è a idrogeno
Centinaia di vittime per aver scaricato un torrent pirata infetto: colpito anche The Odyssey
File di Excel illeggibili su LibreOffice? La colpa è di Microsoft secondo TDF
Grok 4.7 raddoppia la velocità e dimezza i costi dei rivali. È pensato per programmare per ore
Sembra uscito da Halo ma è un case per PC: Corsair WARTHOG sulle orme di un mito del passato
Fable 2 su PC a 60 FPS: il port non ufficiale che anticipa il reboot 2027
Amazfit T-Rex Dual Solar: ecco il nuovo smartwatch rugged che si ricarica con il sole
Fermati 45 maxi-progetti IA negli USA. Trump: 'Vogliono restare poveri'









24 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info....
Ma ciò non implica assolutamente (e non è proprio così
.....
Il codice che un compilatore può generare può essere diverso, oppure esattamente uguale, ma questo nessuno lo garantisce
Hai ragione, java non definisce uno standard di compilazione programmaticamente (Un approccio interessante utilizzato ad esempio in Squeak in cui la VM viene generata a partire da una codice di alto livello, in modo da garantire un esecuzione bit-identica su differenti architeture) , ma fornisce specifiche documentali.
Ma dato che quello che si sta producendo e' bytecode che deve essere conforme all'architettura specificata della JVM, le differenze prodotte da vari compilatori sono relativamente ridotte. (E' chiaro che si possono o no utilizzare algoritmi per fare inlining, come tipicamente avviene per i field e metodi final, e altre cose, ma si tratta di ottimizzazioni rispetto all'architettura della JVM, non rispetto alla macchina fisica che seguira' il codice)
Da questo punto di vista il bytecode ha si subito una prima fase di elaborazione, ma questa non e' dipendente dalla macchina fisica su cui verra' eseguito.
Che sia più difficile generare codice macchina efficente a partire dal bytecode mi sembra un po' bizzarro. Sono tutto fuorchè un esperto di codice macchina, tuttavia il set di istruzioni per la macchina virtuale java è nato con la specifica esigenza di essere "silicabile" (orrendo termine [Chang 1997]), come per altro ancora testimoniato nell'introduzione alle specifiche della JVM (Sun, The Java Virtual Machine Specifications, 2nd ed.).
Questo e' il secondo step di compilazione, che a questo punto puo' essere specifico a seconda dall'implementazione della JVM per l'architettura fisica.
L'ottimizzazione e' basata sul bytecode prodotto e non vedo difficolta rispetto a quella del sorgente originario (E' una rappresentazione in larga parte 'equivalente' )
Certamente c'e' un trade-off: alcune delle scelte di ottimizzazione fatte durante la compilazione Sorgente-Bytecode possono avere impatti diversi su diverse JVM. Un processo di compilazione unico Sorgente-Codice macchina potrebbe essere potenzialmente piu' efficiente anche se non portabile (e quindi addio ad uno dei benefici di java, non potrei usare il mio IDE preferito sotto windows e sotto linux
Se il bytecode non può sfruttare, ad esempio, il set SSE, non è detto che non possa farlo il compilatore JIT (personalmente però ho forti dubbi che la HotSpot vada a verificare il tipo di processore).
Anch'io ho forti dubbi, dal codice delle librerie di java (mi vengono immente il Java3D o l'ImageToolkit), molte scelte di ottimizzazione per piattaforma sono trattate a livello applicativo con pattern di tipo AbstractFactories per istanziare implementazioni alternative, che magari si agganciano a API native.
Discorso interessante, se qualcuno ha altre info, sono curioso
Ciao
P.S. Il pattern "AbstractFactories" a cui ti riferisci è il famoso "Facade" pattern (con la "c" spagnola)?
Ti faccio un breve esempio:
In pratica esiste una classe astratta (questa e' l'Abstract Factory) che ha un metodo statico per costruire un oggetto; questo metodo richiama un metodo di istanza della factory concreta.
L'oggetto restituito implementa un interfaccia (E qui ci sta il Façade pattern
Su internet si trovano un sacco di pagine sui pattern, ma io partirei dal mitico wiki di Ward Cunningham:
http://www.c2.com/cgi/wiki?AbstractFactory
Ciao
Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".