Enfin, les vieilles le faisaient, mais une JVM digne de ce nom, au même titre que l'environnement .NET, compile le byte-code au moment ou elle le charge. Pour du C, si tu considères que
#!/bin/sh
gcc hello.c && ./a.out && rm ./a.out
interprête le code C, alors, la JVM interprête le byte-code. Si tu considères que le script ci-dessus compile puis execute en natif le code, alors la JVM aussi.
> Elle envoie le bytecode au cpu sans rien faire ? Mais oui....
Ben non, elle le compile avant !
> Tu fais tes tests avec dmalloc (c'est lent mais il contrôle les débordements comme java (ou presque)).
Tu fais bien d'ajouter le *ou presque*. Disons que ca n'a pas grand chose à voir. En C, avec un déboggeur mémoire (j'utilise valgrind. Je suppose que dmalloc fait à peu près la même chose), tu peux vérifier que sur une execution donnée, il n'y a pas eu de débordement de mémoire. En Java, les débordements de mémoire sont impossibles par construction du language. Aux bugs de la JVM près, il ne peut donc y avoir de débordement mémoire sur *aucune* execution possible.
Ca, c'est au niveau Java. Au niveau byte-code, il y a un vérificateur de byte-code qui vérifie que le byte-code est bien typé au chargement, ce qui te permet le même genre de propriété. Le résultat, c'est que tu peux par exemple charger un programme à toi et un programme a qui tu ne fais pas confience dans la même JVM (Dans des threads séparés). Tu as la garantie que l'autre application ne pourra pas écrire dans ta mémoire.
[^] # Re: Excellent
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Le code de Java3D est disponible. Évalué à 2.
Non.
Enfin, les vieilles le faisaient, mais une JVM digne de ce nom, au même titre que l'environnement .NET, compile le byte-code au moment ou elle le charge. Pour du C, si tu considères que
#!/bin/sh
gcc hello.c && ./a.out && rm ./a.out
interprête le code C, alors, la JVM interprête le byte-code. Si tu considères que le script ci-dessus compile puis execute en natif le code, alors la JVM aussi.
> Elle envoie le bytecode au cpu sans rien faire ? Mais oui....
Ben non, elle le compile avant !
> Tu fais tes tests avec dmalloc (c'est lent mais il contrôle les débordements comme java (ou presque)).
Tu fais bien d'ajouter le *ou presque*. Disons que ca n'a pas grand chose à voir. En C, avec un déboggeur mémoire (j'utilise valgrind. Je suppose que dmalloc fait à peu près la même chose), tu peux vérifier que sur une execution donnée, il n'y a pas eu de débordement de mémoire. En Java, les débordements de mémoire sont impossibles par construction du language. Aux bugs de la JVM près, il ne peut donc y avoir de débordement mémoire sur *aucune* execution possible.
Ca, c'est au niveau Java. Au niveau byte-code, il y a un vérificateur de byte-code qui vérifie que le byte-code est bien typé au chargement, ce qui te permet le même genre de propriété. Le résultat, c'est que tu peux par exemple charger un programme à toi et un programme a qui tu ne fais pas confience dans la même JVM (Dans des threads séparés). Tu as la garantie que l'autre application ne pourra pas écrire dans ta mémoire.