Pan dans tes dents - Page 7

http://www.jnode.org/

hahaha

Kevin : ouais, enfin faut pas prendre tous les autres développeurs pour des imbéciles non plus, hein. Dans le cas de Kochise, il est évident qu'en cas d'égalité du hash, le système fait une comparaison octet par octet pour vérifier. L'intérêt c'est que rajouter une comparaison de hashes ne coûte quasiment rien en performances dans le pire des cas (je rappelle qu'on dispose des hashes déjà calculés), et fait gagner énormément de temps dans le cas de fichiers différents.

Zut, squalyl a été plus rapide que moi ^^

faudra que je l'essaye une foé.

mais apparemment toutes les classes étaient instanciées dans le meme espace mémoire (ou bien krenle/userland) alors c'est moyen glop quand même.

Wow énorme

oui c'est assez fun, la machine virtuelle est écrite elle même en java, grâce à quelques objets pré instanciées au bootstrap. enfin, le compilateur et l'assembleur JIT sont eux mêmes écrits en java, plus précisément.

j'imagine même pas comment c'est faisable, mais ça l'est

Toute façon, uune jvm elle a toujours besoin de code non-java pour booter j'imagine ?

Il y a des processeurs qui peuvent manger du bytecode.

Je rappelle que c'est pas parce qu'un truc est faisable que c'est pour autant une bonne idée

certainement

Folco: le but de jnode est justement de rendre cette partie du code minimale, mais oui ^^

Bah sincèrement, avoir les drivers dans une VM, je trouve ça une bonne idée, hein ! C'est beaucoup plus sûr pour le système (par contre, niveau perfs, à voir ^^)

Brunni (./180) :

Kevin Kofler (./178) :
Heureusement que KDE est codé en C++!

Ca ok, le système ne devrait pas être codé en Java. Par contre pour les applications c'est pas mal sur le principe.

KDE, c'est aussi des applications.

Folco (./187) :
Toute façon, uune jvm elle a toujours besoin de code non-java pour booter j'imagine ?

Il y a peut-être moyen de s'en sortir avec du Java précompilé, genre avec GCJ.

pas besoin de sortir gcj, toutes les VMs normales savent le faire.

Kevin Kofler (./192) :

Folco (./187) :
Toute façon, uune jvm elle a toujours besoin de code non-java pour booter j'imagine ?

Il y a peut-être moyen de s'en sortir avec du Java précompilé, genre avec GCJ.

Le « genre avec GCJ » est de trop mais oué c'est l'idée… (=> Pour avoir énormément réfléchi à ce sujet… )
En fait la théorie pour faire fonctionner un système comme ça est pas très compliquée. (je connaissais JNode mais je n'ai jamais essayé ni regardé comment ça marcher hein*, donc je peux pas dire exactement comment leur implémentation fonctionne)
Par contre la pratique c'est chiant. (Spour ça que j'ai remis mon projet de faire la même chose en C# à « un jour »)
Enfin en gros, il faudrait que tu précompiles du code pour fabriquer une image mémoire de l'OS tel qu'il serait une fois démarré. Donc ne compiler (AOT) que les méthodes strictement nécéssaires pour démarrer le JIT et la gestion mémoire par exemple. Et le modèle mémoire /JIT/AOT utilisé par l'image statique doit correspondre exactement à la version que tu va charger de manière dynamique. C'est plus complexe à développer (au début en tout cas) qu'un OS normal car il faut que « tout » fonctionne déjà avant de pouvoir obtenir quoi que ce soit. (même un simple bip sur le PC speaker)
La façon dont je m'y prendrais perso serait de compiler l'OS en tant que programme normal sur un OS hôte (c'est de toutes façons le plus simple pour développer ça), puis de générer l'image mémoire avec le faux OS… Et la boucle est bouclée
(Par contre ça demande en effet un OS hôte… mais certainement pas un truc comme GCJ )

*de peur de souiller mon esprit avec des idées pas fraîches (je préfère réinventer la roue )

Oué, en fait tu fais un memcpy(qqpart_en_ram, image_de_vm_bootée_et_en_standby, taille_de_ouf) ; jsr entry_point; et t'auras fait booter ta vm en une ligne hein.
C'est poura ça que le théorie est si simple, mais bonsoir pour construire cette fameuse image ^^

c'est exactement ça.
faut un outil évidemment, c'est une partie importante du projet jnode.
mais bon, si t'as tout défini, c'est tout à fait envisageable.

je crois qu'ils exécutent le boot dans une sorte d'émulateur, puis dumpent les bons bouts de mémoire.

Donc il y a quand même un bout minimal de vm dans un autre langage.

sur le PC qui sert à compiler le bouzin ^^

sinon oui il faut quand même écrire un bout de microkernel, et accroche toi le mec il fait ça en assembleur, oui mossieur

edit: suffit de lire leur site:

Boot image building

When JNode boots, the Grub bootload is used to load a Multiboot compliant kernel image and boot that image. It is the task of the BootImageBuilder to generate that kernel image.

The BootImageBuilder first loads java classes that are required to start JNode into there internal Class structures. These classes are resolved and the most important classes are compiled into native code.
The object-tree that results from this loading & compilation process is then written to an image in exactly the same layout as an object in memory is. This means that the the necessary heap headers, object headers and instance variables are all written in the correct sequence and byte-ordering.
The memory image of all of these objects is linked with the bootstrapper code containing the microkernel. Together they form a kernel image loaded & booted by Grub.

"J'ai un OS en Java !"
"Super, il doit être portable alors ?"
"Ben non, le boot est en asm"

Ben y'a aucun OS 100% portable, hein ^^

./198 >Donc il y a quand même un bout de truc qui n'est pas codé en Java…
Je suis certain que c'est possible de faire sans. (Mais peut-être pas en Java… Le Java n'a pas de pointeurs, d'ailleurs comment ils surmontent ça dans leur VM ?)
Enfin, pour le reste, c'est exactement comme je pensais…

./199 > Enfin Folco, c'est évident que ton processeur n'éxécute que du code qu'il comprend. Et de toutes façons l'OS totalement portable est une utopie. L'avantage d'un OS en langage interprété, c'est que tu vas avoir des services (de base, et éventuellement de niveau supérieur) spécifiques à la machine (la partie qui génère les instructions natives, la gestion de mémoire, etc), mais le coeur et de nombreuses autres parties du systèmes seront exactement les mêmes partout. Ça a quand même un certain avantage. Tu peux fournir des binaires uniques, avec une abstraction matérielle quasi totale. Des drivers "génériques" qui sont installables sur l'OS quel que soit le CPU utilisés (l'EFI permet ça aussi, des drivers en bytecode ).
En gros les composants que tu vas assembler pour former le cœur de ton OS sont individuellement portables (pour la plupart), mais leur union ne l'est pas. (C'est la théorie en tout cas)

http://gitorious.org/jnode/svn-mirror/blobs/master/core/src/core/org/jnode/vm/Unsafe.java
http://gitorious.org/jnode/svn-mirror/blobs/master/core/src/core/org/jnode/vm/VmAddress.java
et plus généralement
http://gitorious.org/jnode/svn-mirror/trees/master/core/src/core/org/jnode/vm

GoldenCrystal (./201) :
Donc il y a quand même un bout de truc qui n'est pas codé en Java...

Ben dans tout OS qui tourne sur une vraie machine, y'a forcément un bout en assembleur (à part les processeurs qui exécutent un autre langage nativement).

Oué nan mais je m'en doute, on a pas encore trouvé la chaine binaire qui s'exécute sur tous les procs et serait capable d'identifier le proc sur lequel elle tourne, puis de prendre la main en d'une manière ou d'une autre en fonction

squalyl (./193) :
pas besoin de sortir gcj, toutes les VMs normales savent le faire.

Euh non, Sun ne livre qu'un JIT, pas de compilateur AOT.

squalyl (./202) :
http://gitorious.org/jnode/svn-mirror/blobs/master/core/src/core/org/jnode/vm/Unsafe.java

Du JNI quoi, encore du code non-Java.

sans blague

./203 > Tu pourrais faire entièrement sans. Il me semble d'ailleurs que c'est déjà possible avec les images multiboot (utilisées par GRUB), qu'utilise déjà JNode d'après ./198 .
Actuellement sur x86 c'est la merde parce que c'est encore totalement rétro-compatible avec les CPU 16 bits, donc ton système démarre dans un état indéterminé. Tu dois éxécuter du code pour vérifier que tu te lances bien sur la machine attendue, car ton code peut s'exécuter (avant de crasher) sur une machine où il ne devrait pas pouvoir . (C'est une des choses qui m'a le plus fait fuir. Ça et la complexité incroyable du jeu d'instruction x86…)
Mais si tu utilises des abstractions de plus haut niveau comme EFI (ou GRUB, enfin bof), tu peux très bien te démerder à faire ce que tu veux. Ah certes, tu exécuteras du code natif que tu n'as pas écrit. Mais tu t'en fous, c'est un truc standard, et ton OS démarrera directement dans un état connu. Inutile de dire qu'à partir de là tu peux déjà quasiment faire ce que tu veux… Tout au moins, en C# tu pourrais (et je pense qu'en Java aussi mais j'en mettrai pas ma main à couper non plus).
Enfin, évidemment faut que tout soit bien ficelé. Mais qu'est-ce qui va t'empêcher de gérer les pages mémoire ou de gérer les différentes tâches à partir de code JITté ?
Tu as quelques instructions (LGDT par exemple) qu'il va falloir représenter par une méthode spéciale (implémentation par le runtime ^^), mais c'est le boulot du JIT/AOT de s'occuper de ces cas spéciaux. Et le JIT/AOT est déjà spécifique à la plate-forme.
Tu auras juste des contraintes particulières sur les opérations que tu peux effectuer quand tu es à l'intérieur d'un service critique du système, mais je vois pas en quoi ça t'empêche de faire ce qu'il faut.
(Typiquement: Tu ne peux pas allouer un nouvel objet dans le code qui gère les allocations mémoire.
En effet en Java qui n'a pas stackalloc et System.ValueType, ça pourrait poser problème, là encore )

Folco (./204) :
Oué nan mais je m'en doute, on a pas encore trouvé la chaine binaire qui s'exécute sur tous les procs et serait capable d'identifier le proc sur lequel elle tourne, puis de prendre la main en d'une manière ou d'une autre en fonction

Non, mais l'architecture x86 fonctionne déjà un peu sur ce principe…
Est-ce que je suis sur un processeur 32 bits ? Ah oui, on dirait…
Attends je passe en mode 32 bits…
Est-ce que j'ai le droit à utiliser beaucoup de mémoire ? Ah oui on dirrait aussi…
Ah peut-être que je suis même 64 bits ? Bingo !
Bon, quel modèle ?
Hmm oh, celui là ! Je le connais pas. Alors attends hmm, j'ai le droit à cette instruction, celle là, et celle là, mais pas celle-là ni celle-là.

Et j'a même pas abordé le sujet de détecter la mémoire disponible… Je crois qu'on pourrait en écrire des romans… Enfin pas moi, car je trouve ça horriblement pénible et ennuyeux comme sujet, donc j'évite de trop me pencher dedans. (Enfin, c'est surtout que ça me boufferait des journées entières sans que je m'en rende compte, mais mon temps de glande est trop précieux pour que je perde des journées à me documenter sur des trucs 3/4 obsolètes :/)

Oui, ma remarque s'appliquait aux cas où il n'y a pas d'intepréteur de bytecode, genre EFI.

GoldenCrystal (./208) :
Ça et la complexité incroyable du jeu d'instruction x86

Meuh non, ce n'est pas si complexe