Est-ce que Java enregistre ses optimisations d'exécution?

Question

Mon professeur a fait une référence informelle sur un petit programme et les temps en Java étaient les suivants: 1,7 seconde pour la première analyse et 0,8 seconde pour les analyses suivantes.

• Cela est-il entièrement dû au chargement de l'environnement d'exécution dans l'environnement d'exploitation?

  OU

• Est-ce influencé par l'optimisation du code par Java et le stockage des résultats de ces optimisations (désolé, je ne connais pas le terme technique pour cela)?

Answer 1

Je conviens que la différence de performances observée par l’affiche est très probablement due à la latence des disques, qui restitue le JRE en mémoire. Le compilateur Just In Time (JIT) n’aurait pas d’impact sur les performances d’une petite application.

Java 1.6u10 ( http://download.java.net/jdk6/ ) les fichiers JAR d'exécution dans un processus en arrière-plan (même si Java n'est pas en cours d'exécution) pour conserver les données dans le cache du disque. Cela réduit considérablement les temps de démarrage (ce qui représente un avantage considérable pour les applications de bureau mais une valeur probablement marginale pour les applications côté serveur).

Sur des applications volumineuses et longues, le JIT fait une grande différence dans le temps - mais le temps requis par le JIT pour accumuler suffisamment de statistiques pour démarrer et optimiser (5 à 10 secondes) est très, très court par rapport à la durée de vie globale de l'application (la plupart ont duré des mois et des mois). Bien que la mémorisation et la restauration des résultats de l’ECM constituent un exercice académique intéressant, l’amélioration pratique n’est pas très importante (c’est pourquoi l’équipe de l’ECI s’est davantage concentrée sur des stratégies telles que les stratégies de GC pour réduire les oublis de mémoire cache, etc.).

La pré-compilation des classes d'exécution aide beaucoup les applications de bureau (tout comme le préchargement du cache disque 6u10 susmentionné).

Answer 2

D'accord, j'ai trouvé où j'ai lu ça. Tout cela provient de " Learning Java " (O'Reilly 2005):

  

Le problème avec une compilation JIT traditionnelle est que l'optimisation du code prend du temps. Ainsi, un compilateur JIT peut produire des résultats décents mais peut subir une latence importante au démarrage de l’application. Cela ne pose généralement pas de problème pour les applications côté serveur de longue durée, mais constitue un problème sérieux pour les logiciels côté client et les applications exécutées sur des périphériques plus petits aux capacités limitées. Pour remédier à cela, la technologie de compilation de Sun, appelée HotSpot, utilise une astuce appelée compilation adaptative. Si vous regardez quels programmes passent réellement leur temps à faire, il s'avère qu'ils passent presque tout leur temps à exécuter encore et encore une partie relativement petite du code. Le bloc de code qui est exécuté à plusieurs reprises peut ne représenter qu'une petite fraction du programme total, mais son comportement détermine les performances globales du programme. La compilation adaptative permet également au moteur d’exécution Java de tirer parti de nouveaux types d’optimisations qui ne peuvent tout simplement pas être réalisées dans un langage compilé de manière statique, d’où l’affirmation selon laquelle le code Java peut être plus rapide que C / C ++ dans certains cas.

     

Pour tirer parti de ce fait, HotSpot est au départ un interpréteur de bytecode Java normal, mais avec une différence: il mesure (établit des profils) le code en cours d’exécution pour voir quelles parties sont exécutées de manière répétée. Une fois qu'il sait quelles parties du code sont essentielles à la performance, HotSpot compile ces sections en un code machine natif optimal. Comme il ne compile qu'une petite partie du programme en code machine, il peut se permettre de prendre le temps nécessaire pour optimiser ces parties. Il n’est peut-être pas nécessaire de compiler le reste du programme, il suffit de l’interpréter, pour économiser de la mémoire et du temps. En fait, la machine virtuelle Java par défaut de Sun peut s’exécuter selon l’un des deux modes suivants: client et serveur, qui lui permettent de souligner le temps de démarrage rapide et la conservation de la mémoire ou les performances optimales.

     

Une question naturelle à poser à ce stade est la suivante: pourquoi jeter toutes ces informations de profilage valables chaque fois qu'une application est fermée? Eh bien, Sun a partiellement abordé ce sujet avec la publication de Java 5.0 en utilisant des classes partagées en lecture seule, stockées de manière permanente dans un formulaire optimisé. Cela réduit considérablement le temps de démarrage et les frais généraux liés à l'exécution de nombreuses applications Java sur une machine donnée. La technologie utilisée est complexe, mais l’idée est simple: optimisez les éléments du programme qui doivent aller vite et ne vous inquiétez pas du reste.

Je me demande en quelque sorte à quel point Sun en est-il depuis Java 5.0.

Answer 3

Je ne connais aucune machine virtuelle largement utilisée qui enregistre des données d'utilisation statistique entre les invocations de programmes - mais il s'agit certainement d'une possibilité intéressante pour les recherches futures.

Ce que vous voyez est probablement dû à la mise en cache du disque.

Answer 4

Je conviens que cela est probablement dû à la mise en cache du disque.

Pour votre information, la machine virtuelle IBM Java 6 contient un compilateur anticipé (AOT). Le code n'est pas aussi optimisé que ce que le JIT produirait, mais il est stocké sur des machines virtuelles, je crois dans une sorte de mémoire partagée persistante. Son principal avantage est d'améliorer les performances de démarrage. Par défaut, la machine virtuelle IBM utilise une méthode après son appel 1000 fois. S'il sait qu'une méthode va être appelée 1 000 fois juste au démarrage de la machine virtuelle (pensez à une méthode couramment utilisée telle que java.lang.String.equals (...) ), alors c'est avantageux pour le stocker dans le cache AOT afin de ne jamais perdre de temps à compiler lors de l'exécution.

Answer 5

Vous devez décrire comment votre test de performance a été réalisé. Surtout à quel moment vous commencez à mesurer le temps.

Si vous incluez l'heure de démarrage de la machine virtuelle Java (utile pour l'analyse comparative de l'expérience utilisateur mais non utile pour l'optimisation du code Java), il peut s'agir d'un effet de mise en cache du système de fichiers ou peut être provoqué par une fonctionnalité appelée "Données de classe Java". Partage ":

Pour Sun:

http: // java .sun.com / j2se / 1.5.0 / docs / guide / vm / class-data-sharing.html

Il s'agit d'une option dans laquelle la machine virtuelle Java enregistre une image préparée des classes d'exécution dans un fichier, afin de permettre un chargement (et un partage) plus rapide de celles-ci au prochain démarrage. Vous pouvez contrôler cela avec -Xshare: on ou -Xshare: off avec une JVM Sun. La valeur par défaut est -Xshare: auto, ce qui chargera l’image de classes partagées si elle est présente et, si elle n’est pas présente, elle l’écrira au premier démarrage si le répertoire est accessible en écriture.

Avec IBM Java 5, BTW est encore plus puissant:

http://www.ibm.com/developerworks/java/ bibliothèque / j-ibmjava4 /

Je ne connais aucune machine virtuelle Java traditionnelle enregistrant des statistiques JIT.

Answer 6

La machine virtuelle Java Java (qui peut en réalité changer d’implémentation différente de la machine virtuelle Java) au premier démarrage interprétera le code octet. Une fois qu'il a détecté que le code sera exécuté suffisamment de fois, le JIT le convertira en langage machine natif pour qu'il s'exécute plus rapidement.