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









50 anni e non sentirli, SAS innova su IA, digital twin e quantum computing
Tesla Model 3 dopo 5 anni di utilizzo e 158.000km
DJI Mic Mini 2: audio 48 kHz / 24-bit e protocollo OsmoAudio sotto i 100 Euro
Commodore 64 e ZX Spectrum come non li avete mai visti: per la prima volta in versione portatile
OnePlus ha svelato un nuovo tablet con Snapdragon 8 Elite Gen 5
Samsung Galaxy S27: restyling in arrivo, ecco cosa potrebbe cambiare
La crisi delle memorie colpisce ancora: prezzi alle stelle per Steam Machine e Steam Frame?
TCL lancia la serie K: tre nuovi smartphone di fascia bassa pronti a conquistare il mercato italiano
Engwe esagera: 700 euro di sconto su e-bike in carbonio, e promo su modelli con triplo e quadruplo ammortizzatore
Star Wars: Galactic Racer ha una data ufficiale e due edizioni speciali
Il piano di Huawei funziona davvero? HarmonyOS vola e punta a conquistare il mondo
Samsung Foundry migliora ancora: rendimento in crescita per i chip a 4 nm
L.A. Noire: Take-Two chiarisce la situazione in merito a un possibile sequel
Vision Pro è un flop: Apple è pronta ad accettare il fallimento del progetto
Fractal Design Pop 2 Vision potrebbe essere il case compatto che stavate aspettando
La tecnologia GaN arriva sulle auto elettriche: più efficienza, meno ingombro, ideale per le city car
Beeple trasforma Musk, Bezos e Zuckerberg in cani robot che 'espellono' stampe e NFT









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".