En 2000, le marché des puces Java, de Sun Microelectronics, devait peser au moins 15 milliards de dollars. Des prévisions grandioses et euphoriques, que le constructeur annonçait haut et fort en 1996.
En 1997, Sun publiait les premières spécifications d’un processeur Java 32 bits, picoJava, capable d’exécuter directement la plupart des instructions les plus courantes. Les instructions complexes étant, quant à elles, microcodées, ou interceptées et émulées par logiciel. Principal avantage d’un tel processeur, éviter la phase d’interprétation nécessaire dans le cas de l’utilisation d’une machine virtuelle Java (JVM) ou d’un compilateur à la volée (JIT).
Les spécifications picoJava II, en 1999, visent à améliorer les performances : meilleure gestion du cache, et possibilité de charger et d’exécuter les instructions sur un seul cycle. Quatre années ont passé, et la dure réalité a renvoyé Sun à ses calculs. Le club des cinq licenciés du modèle de référence picoJava de Sun (IBM, Fujitsu, LG Semicon, NEC et Rockwell Collins) ne s’est pas agrandi. Et si le modèle de référence compte à son actif plus de mille téléchargements depuis le site du constructeur, l’industrie des semi-conducteurs souffre toujours d’une pénurie criante de ce type de processeur, d’autant que Sun, dès 1998, a lui-même abandonné l’idée de se lancer dans la production de picoJava.
Associer une machine virtuelle à un OS temps réel
Pourtant, ce réel échec n’empêche pas le concept de poursuivre son petit bonhomme de chemin. Le dernier salon JavaOne, qui s’est tenu début juin à San Francisco, s’est même fait l’écho d’un regain d’intérêt pour cette technologie. Rarissimes il y a encore deux ans, les nouveaux adeptes d’un Java gravé sur une tranche de silicium – picoJava ou non -, à l’instar d’aJile, de Zucotto, ou encore de Vulcan Asic, sont de plus en plus nombreux (voir le tableau ci-après). Il faut dire que le potentiel demeure alléchant, quoi qu’il arrive. Pour justifier sa puce Cjip, le Suédois Imsys met en avant une étude menée en 1999 par Venture Development, qui estime que, en 2003, le nombre d’appareils à base de Java embarqué devrait dépasser les vingt-quatre millions, contre environ deux millions en 2000. Certes, mais encore reste-t-il à savoir quelle sera la configuration la plus adaptée pour enfouir Java dans cette multiplicité d’équipements électroniques, boîtiers internet, décodeurs TV, téléphones mobiles, webphones et autres assistants personnels, voire, à plus lointaine échéance, au sein des équipements électroménagers.
La tendance actuelle consiste le plus souvent à associer une machine virtuelle (JVM) – Personal Java pour le profil le plus répandu – à un système d’exploitation temps réel (SETR). A ce titre, certains fournisseurs de processeurs Java avancent l’argument que le prix par appareil des licences d’utilisation d’une machine virtuelle – de 2 à 9 dollars pour Personal jWorks, de Wind River – et d’un OS temps réel – de 1 à 16 dollars pour VxWorks – peut excéder le coût unitaire de processeurs fabriqués à la chaîne.
La puce consomme moins que les composants
Au-delà de ces considérations économiques, la puce Java présente des arguments purement techniques face au couple ” machine virtuelle-OS temps réel “. En effet, ce dernier, pour optimiser ses performances, fera appel à des mécanismes de compilation – native ou à la volée – très gourmands en ressources mémoire. Or, “les composants mémoire consomment nettement plus d’énergie que le processeur lui-même “, signale Jean-François Baillot, ingénieur d’applications chez Sun Microelectronics France. Avec le processeur Java, au contraire, l’encombrement mémoire est bien moindre, puisque le ” byte-code ” Java devient le langage machine du processeur : la compilation n’est plus nécessaire, l’espace mémoire peut se réduire, et la consommation d’énergie – élément capital pour les équipements alimentés par batterie – décroît.
Différentes solutions techniques ont cours. Une approche consiste à concevoir des coprocesseurs destinés à être couplés à un processeur principal, comme JStar de Jedi, ou encore JVX d’inSilicon. Dans le principe, ces accélérateurs interceptent les instructions Java en mémoire et les transcrivent à destination d’un processeur cible. Pour JStar, ce peut être un processeur Risc ou Cisc de 8 à 64 bits, tandis que JVX couvre tous les processeurs 32 bits à bus externe (Mips, ARM, SH3, PowerPC, Intel X86 ou Motorola 68K. ).
Le coprocesseur Java fait le lien avec Mips et ARM
D’autres, tels Imsys, Zucotto, Patriot Scientific, ou LG Semicon, ont conçu de véritables processeurs Java incorporant le plus souvent un noyau temps réel. Ces puces, gravées parfois en technologie 0,25 micron, assurent des performances de bonne tenue. Certains, comme Vulcan Asic, ont privilégié le gain de place : son processeur Moon n’occupe que le tiers de la taille d’un c?”ur picoJava, 80 % du jeu d’instructions d’une machine virtuelle étant câblé. Les partisans de la première heure, comme IBM ou NEC, ne semblent pas avoir beaucoup avancé sur ce terrain. IBM ne communique plus sur le circuit intégré applicatif qu’il comptait réaliser en 1998. Quant à NEC, la puce d’évaluation qu’il a conçue n’a pu encore trouver de débouché commercial.
Pour autant, les avantages incontestables de ces puces, dans l’hypothèse de l’adoption de Java à grande échelle dans l’informatique embarquée, ne peuvent faire oublier la domination sans partage des processeurs Mips et ARM sur ce segment de marché. Par exemple, cent quatre-vingts millions de périphériques équipés de processeurs ARM ont été vendus en 1999. Un espoir toutefois pour les partisans de Java : ces deux familles de processeurs en arrivent à adopter le langage de Sun par adjonction de coprocesseurs Java, comme ceux de Jedi ou d’inSilicon. Les chances de Java de se voir fondu dans le silicium tiendront peut-être dans ce compromis.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
