Discussion :

[ClaudeBg]

Salut
-----

J'envisage une application sur base d'une carte genre pandaboard (pour donner un exemple concret) sur lequel tournerait un Linux + Xenomai installé sur carte SD.

Il s'agit de mémoire flash, donc la durée de vie en écriture est limitée, et donc on ne peut pas y écrire à répétition comme sur un HD.

Ma question est simple : si j'utilise un langage utilisant un compilateur JIT (Java ou C#/Mono), ce JIT va-t-il écrire sur la carte SD à chaque exécution du programme... ou la compilation sera-t-elle unique tant qu'on ne change pas le programme?

Question subsidiaire : Je ne connais pas bien Java, si je l'utilise, puis-je compiler pour obtenir du code natif et non du code IL, ce qui me permettrait d'éviter le JIT?

Merci d'avance,
Claude

[ArKam]

Normalement, si je dit pas de conneries le JIT vas compiler les blocs de programmes uniquement quand ceux-ci sont requis, mais, par contre, je ne sais pas si tu peux forcer la compile unique au démarrage du logiciel.

Pour java le code natif c'est du JAR, donc oui ça existe, par contre, je ne fait pas de java donc je vais pas pouvoir trop t'aider sur ce point.

[gorgonite]

la question est surtout de savoir s'il ne va faire du JIT qu'en Ram, ou s'il va devoir swaper... question qui ne se pose pas tellement sur des environnements classiques


sinon il y a moyen de désactiver le JIT... voire d'utiliser des machines virtuelles alternatives, plus adaptées à l'embarqué en Java

exemples

• mono et --full-aot
• Sun Java et -Xint
• Java via la Sun KVM, la JVM Esmertec et son DAC, etc

[ClaudeBg]

Salut
-----

La question est surtout de savoir s'il ne va faire du JIT qu'en Ram, ou s'il va devoir swaper... question qui ne se pose pas tellement sur des environnements classiques

Oui, c'est exactement ça.
J'ai besoin de pouvoir créer une solution où il n'y a pas d'écriture disque, ou alors uniquement lors de la première exécution.

J'aimerais aussi pouvoir utiliser C# en mono, et de nouveau les mêmes questions se posent.

Comme tu l'indiques ce sont des interrogations qui n'intéressent personne... tant qu'on ne se retrouve pas avec ce genre de contraintes, et donc les réponses ne sont pas simples à dénicher

A+
Claude

[ArKam]

Bonjour,

Je dirais que ça vas surtout dépendre de ton OS.

Par exemple, sous Android, il y a un compilateur JIT cependant, par defaut, la plateforme n'a pas forcement une carte SD de rattachée, pourtant le JIT fonctionne quand même.

D'intuition je dirais que le JIT vas fonctionner en RAM quitte à ce créer un ramdisk pour le cache temporaire.

Pour moi, pas de souci vis à vis de la carte SD.

[ClaudeBg]

Salut
-----

Merci pour ces précisions.

Le choix ne sera probablement pas Android car la carte ne contiendra aucun afficheur type "GSM" ou "tablette", mais fonctionnera sans écran, avec possibilité de connecter en cas de mise à jour un écran "standard". Ce sera donc probablement un Linux "standard".

Partant de là, une question m'interpelle :

Comment le compilateur JIT sait-il qu'il tourne sur une flash ou sur un HD? En effet, s'il se comporte différemment ça doit être signalé quelque part?


A+
Claude

[ArKam]

A mon avis, le compilateur ne sais pas ou il se trouve, cependant l'OS oui.
Donc si tu fait tourner ton OS en RAM c'est bon.

Après, j'avoue que je ne connais pas Java et JIT plus que ça donc...

Pour le coups, ton problème devrait être facile à résoudre pour quelqu'un qui fait du Java et qui utilise JIT, pas forcement que en embarqué.

Sinon, je connais quelqu'un qui developpe pas mal sous Android, du cout je peux lui demander de passer jeter un oeil.

Même si tu développe pas sous Android, Java c'est Java et JIT bah pareil

[monnoliv]

Pourquoi ne pas créer un ramdisk e tout faire en RAM?

[ArKam]

C'est ce que je lui proposai comme solution plus haut.

[ClaudeBg]

Salut
-----

Donc si tu fait tourner ton OS en RAM c'est bon.

Oui, mais la RAM est une ressource limitée en embarqué, et la RAM je vais devoir en réserver une bonne partie pour un programme qui va, lui, tourner en temps réel sous Xenomai. Si je peux économiser la RAM, c'est tout bénéfice pour moi : l'OS en RAM c'est plus simple, évidemment, mais c'est la solution de consommation maxi.

Sinon, je connais quelqu'un qui developpe pas mal sous Android, du cout je peux lui demander de passer jeter un oeil.

Merci.

En fait, une partie sera codée en Java (pas par moi), mais une autre en C# (par moi) sous Mono, il y a donc 2 JIT, d'où ma question de départ.

La flash est en lecture/écriture, ce n'est pas grave si au premier lancement de l'application ça compile et ça écrit, ce que je veux vérifier c'est si ça écrit en permanence à chaque lancement de l'application (destruction de la flash), ou une seule fois lors de la toute première exécution (ça, c'est bon).

A+
Claude

[monnoliv]

Hum, petit calcul: supposons que ton prg est executé 10x par jour, une flash tient 100000 réécriture, donc tu en as pour 100000/365/10 = 27 ans c'est pas mal pour commencer. Ceux qui utilisent des SSD ont moins de scrupules (mais il est vrai que les contrôleurs SSD optimisent les accès et évitent d'écrire toujours sur les mêmes blocs flash).

[ClaudeBg]

Salut
-----

Hum, petit calcul: supposons que ton prg est executé 10x par jour, une flash tient 100000 réécriture, donc tu en as pour 100000/365/10 = 27 ans c'est pas mal pour commencer.

C'est clair, je suis bien d'accord.

C'est juste que les logiciels vont tourner en permanence (la carte sera sous tension 24H/24 365 jours/an. Et vu que j'ignore tout de la façon dont le JIT va se comporter en écriture dans la mémoire programme j'essaye de comprendre pour évaluer au maximum ce qui va se passer en pratique.

J'essaye en fait de savoir si, en installant un nouveau soft :

1) A chaque première utilisation d'une partie du code, le JIT compile, sauve la partie compilée en mémoire programme, et du coup ne recompile jamais plus tant qu'on ne modifie pas le code en question.

2) Ou si le Jit compile à la première utilisation du code du programme lancé, mais doit recommencer la compilation si on stoppe le programme puis qu'on le relance.

Exprimé autrement : la compilation effectuée par le JIT est-elle permanente ou valable pour une seule exécution du programme?

C'est un projet qui sera open-source et qui devrait en principe être repris par une communauté à terme. Je ne voudrais pas poser les bases de quelque chose de caduc.

Si la réponse est "1", alors aucun soucis.
Si la réponse est "2", j'ai plutôt intérêt à essayer de compiler en natif, ou alors de laisser les programmes en service sans les lancer à la demande.

En tout cas, c'est sympa de me répondre, merci


A+
Claude

[monnoliv]

En ce qui concerne C#, il me semble avoir vu une option qui permet de compiler le code directement en code assembleur (qui dépend du processeur donc) et non pas en code intermédiaire.
Il doit bien avoir cette sorte d'option pour toi, non? Faut peut-être poser la question dans le forum Java (en lisant les posts de ce fil, je m'aperçois qu'on en revient au début ) ?
Bonne chance

[ArKam]

Bien, apparemment, sur du x86 et sous des outils microsoft, ça donne une compile puis c'est fini.

http://www.google.fr/url?sa=t&source...A2akd-MHr4pMiw

Et sinon, sur le fonctionnement de JIT en lui meme y'a pas grand chose à par des definitions :/

Edit: Et meme là, y'a pas grand chose http://jmdoudoux.developpez.com/cour...-jvm.php#jvm-5

[monnoliv]

J'ai trouvé ça, le Native Image Generator:
http://en.wikipedia.org/wiki/Native_Image_Generator

[ClaudeBg]

Salut
-----

Merci pour l'aide.

Je vais lire les documents pointés, et éventuellement partir de là pour un complément d'informations.

A+
Claude

[gorgonite]

comme dit plus haut, le plus simple si vraiment tu as peur de cette éventualité est d'avoir ton root en read-only, et un /var en ramdisk (tmpfs ?)

[ClaudeBg]

Salut
-----

comme dit plus haut, le plus simple si vraiment tu as peur de cette éventualité est d'avoir ton root en read-only, et un /var en ramdisk

Oui c'est clair qu'il reste cette possibilité.

D'après ce que j'ai lu ces jours-ci, en lisant "en filigranes", le code machine serait conservé tant qu'on ne modifie pas l'application.

Du coup, je doit d'abord commander la carte (en rupture de stock), et une fois reçue, je vais expérimenter en pratique comment se comporte le JIT dans cet environnement (en JAVA et en Dotnet sous Mono).

Ensuite, je ressortirai ce sujet et je viendrai y dire ce que j'ai constaté dans la pratique, je suis certain que ça servirais à d'autres.

En tout cas, merci des informations

A+
Claude

[ArKam]

Salut,
Du coup, je doit d'abord commander la carte (en rupture de stock)

En tout cas, merci des informations

A+
Claude

Tu serais pas en train de commander une pandaboard par hasard?

[cs_ntd]

Je suis quasiment certain d'avoir lu quelque part (et sur MSDN j'en suis sûr), que pour l'éxécution de code MSIL (et donc C# compilé), le CLR ne fait pas tout le temps appel au JIT compiler, mais qu'il garde en cache, soit des morceaux de l'application qu'il avait linké auparavant, soit qu'il génére à chaque éxécution le code natif dans le cache, soit qu'il met en cache "définitivement" l'application, suivant les options de compilation.
Le but de l'article était de dire que par ce mécanisme, on arrivait à garder une rapidité identique à un programme classique compilé en natif, sauf à la première éxecution qui génère le code natif dans le cache.

Bien entendu, je ne retrouve plus ce lien . Cependant ça reste du MSDN, donc il faut voir comment mono gère son JIT si jamais tu souhaite utiliser Linux.

Sinon, la doc pour NGen et le JIT compiler : http://msdn.microsoft.com/en-us/library/ht8ecch6.aspx