Compilation native java "hereafter of time compiler"

Pause Café
#1

iaorana les gens :smiley:

Il y a bien longtemps :unamused: , j’utilisais le jdk1.1.5 puis 1.1.6 avec le jit traduisant à la volée le bytecode en code natif …mais bon c’était plutôt lent … Maintenant avec la jvm qui fait de la traduction/optimisation “just in time” du bytecode, j’ai toujours trouvé que “c’était gâché” de voir tout ce travail “foutu à la poubelle” lorsque le programme java était arrêté *.

Je ne suis vraiment pas spécialiste mais ceux qui ont bossé sur la compilation native n’ont ils jamais essayé d’utiliser le travail de la jvm lors d’une cession en mode classique pour récupérer données et info d’optimisation pour qu’au bout d’un certains temps un équivalent natif du programme en bytecode puisse être construit* ?

Est-ce stupide d’imaginer une application tournant en tache de fond qui mette “au chaud” toutes les infos et code natif générés par la jvm et qui au bout d’un certains temps (comme dirait Fernand Reynault) afficherait à l’utilisateur “hé mon gars ton programme en bytecode java que tu utilises depuis 4 jours, ben j’ai suffisamment d’info pour te le reconstruire optimisé en code natif si tu veux!!”
…une sorte de compilation “hereafter of time” quoi…

Merci d’éclairer ma lanterne :smiley:

  • : ce que je dis est il erroné ?
#2

Quel est la différence entre « il y a bien longtemps » et « maintenant ».

[quote=“douarn”]Est-ce stupide d’imaginer une application tournant en tache de fond qui mette “au chaud” toutes les infos et code natif générés par la jvm et qui au bout d’un certains temps (comme dirait Fernand Reynault) afficherait à l’utilisateur “hé mon gars ton programme en bytecode java que tu utilises depuis 4 jours, ben j’ai suffisamment d’info pour te le reconstruire optimisé en code natif si tu veux!!”
…une sorte de compilation “hereafter of time” quoi…[/quote]
Cette approche n’est pas viable car le problème de couverture d’un code n’est pas si simple.

Pour ce qui est de générer du code natif oui c’est possible, mais tu va garder le garbadge collector, par exemple. Ensuite c’est pas quelque chose de beaucoup mis en avant parce que ça viole l’un des principes fondamentale de Java « build onde, run everywhere ».

#3

Merci Misterfreeze, d’avoir pris la peine de me répondre (j’avais un peu peur de dire des bêtises pour être franc :laughing: mais comme c’est une question qui me trotte en tête depuis fort longtemps…)

Il y a bien longtemps : pas de jit (jdk 1.1.5) puis le jit symantec (jdk1.1.6) et maintenant openjdk7 avec hotspot (jit+optimisation) si j’ai bien compris.

Je trouve au contraire que le « build once, run everywhere » est toujours respecté. L’application est toujours distribuée sous forme de bytecode (ou du source) et tourne toujours avec la jvm dans un premier temps et tant que l’utilisateur final le désire.

Par contre localement pourraît être créés un/des exécutables (+ librairies) en parallèle qui collationne les infos/données/code natif récupérés lors des différentes utilisations successives du prog’ et optimise à une “échelle plus globale (celle de l’appli en fonctionnement dans son entier)” que ne peut le faire la jvm.

Ce fichier devenant “au bout d’un certains temps” un exécutable natif ne pouvant être indépendant de l’appli bytecode (pour des questions de respect du « build once, run everywhere » pourquoi pas et peut être pour pouvoir piocher dans le bytecode si besoin était)

[quote=“MisterFreez”]Cette approche n’est pas viable car le problème de couverture d’un code n’est pas si simple[/quote] Comme je l’ai déjà dis, je ne suis pas un spécialiste, bien que je trouve l’idée plutôt séduisante à plus forte raison maintenant que les sources du jdk sont publiées. Je me doute bien que cela doit être bien compliqué comme affaire et qu’il y a le GC entre autre à prendre en compte.

Merci Misterfreeze