2010-06-06 2 views
4

Je travaille avec JNI et essaye de décharger (détruire) la machine virtuelle en utilisant la fonction DestoryJavaVM (la première méthode DetachCurrentThread). Il semble que cela a maintenant une influence sur la VM et il est toujours en hausse après l'appel. J'ai lu dans les vieux messages de Sun que DestoryJavaVM avait des problèmes dans le passé (JDK1.1-1.3 en 2001) mais j'utilise JRE 6 et cela devrait probablement fonctionner maintenant, non? J'ai besoin de charger \ Décharger une machine virtuelle dans le même processus de vie puisque chaque chargement nécessite le chargement d'autres classes. Des idées comment cela peut-il être fait?Comment décharger la JVM d'un processus vivant?

Informations complémentaires:

A la phase de déchargement je peux avec succès detachCurrentThread et destroyVM (à la fois retour JNI_OK). J'ai même FreeLibray (jvm.dll) réussi (return 1). Lorsque j'essaie de charger à nouveau la JVM, je peux LoadLibrary(), puis trouver la fonction CreateVM dans la DLL et l'appel à CreateVM échoue (return -1). Qu'est-ce que je fais mal ici?

Merci, Guy

Répondre

2

Bien qu'il ne serait pas répondre à votre question sur DestroyJavaVM. OSGi vient à l'esprit que vous pouvez mettre toutes les classes dans un paquet activer le code d'exécution et le désactiver, plus tard, vous utilisez un autre paquet. Voir Apache Felix.

Une autre option moins élégante serait de quitter le vm et de le redémarrer avec un autre classpath.

+0

+1 Bonnes alternatives. – trashgod

+0

Je ne vais pas à la solution OSGi, désolé. S'il vous plaît voir les informations supplémentaires peut-être vous pouvez aider. – Guy

1

Vous pouvez rechercher des threads erronés. The Invocation API: Unloading the VM mentionne, "La machine virtuelle attend que le thread en cours soit le seul thread utilisateur non démon avant qu'il ne soit réellement déchargé." Ceci est requis par le Java Language Specification, 12.8.

+1

Cela peut créer un problème pour une application suffisamment complexe pour laquelle vous n'avez pas le contrôle total de tous les threads (c'est-à-dire des bibliothèques tierces). Je dirais qu'il est préférable de revoir la conception pour que la JVM recharge les classes (par exemple, OSGi). Pourtant, cela répond probablement à la question du PO. –

+0

J'utilise JRE 1.6 pour que le Destroy fonctionne. Voir mes informations supplémentaires que j'ai ajouté à mon message original. – Guy

+1

@Guy: Vous mentionnez que le deuxième appel à 'JNI_CreateJavaVM()' renvoie -1. Que dit 'ExceptionOccurred()'? – trashgod

0

DestroyJavaVM() ne prend pas en charge le déchargement de la machine virtuelle.

DestroyJavaVM

une machine virtuelle Java Décharge et ses ressources récupère.

Tout thread, qu'il soit attaché ou non, peut appeler cette fonction. Si le thread en cours est connecté, la machine virtuelle attend que le thread en cours soit le seul thread Java de niveau utilisateur non démon. Si le thread en cours n'est pas attaché, la machine virtuelle attache le thread en cours et attend que le thread en cours soit le seul thread de niveau utilisateur non démon.

[...]

Déchargement de la machine virtuelle est pas pris en charge.

La documentation peut sembler un peu contradictoire au début. Ce que vous pouvez faire est de détruire votre VM sans problèmes, mais comme il ne se décharge pas correctement, vous ne pouvez jamais le recharger dans le même processus.