je recherche un algorithme simple, ou une methode issue d'une classe
java libre pour evaluer la charge du CPU du systeme qui heberge la
machine virtuelle java. De preference une methode independante du
systeme et non pas en faisant un test sur le systeme et s'appliquant en
fonction de celui-ci. Il semblerait aue le SDK java 5 Sun contienne une
telle methode mais je recherche en priorite une bibliotheque libre,
pouvant etre execute en environnement 1.4 (voire 1.3) (et cerise sur le
gateau pourquoi pas dans une JVM libre). J'ai d'abord pense a faire une
sorte de benchmark et mesurer le temps d'execution mais on m'a dit aue
c'etait une mauvaise idee. Voila... Merci pour vos idees et conseils.
Installer cygwin ? Tu auras alors la commande uptime comme sur tous les autres unixes.
Il est tres probable que les utilisateurs de l'application ait cygwin mais je ne peux pas considerer ca comme acquis. quitte a etre oblige d'installer une usine a gaz pour avoir une mesure unifiee de la charge du ou des CPU du systeme hote autant installer ce que propose TestMan (pure java, mais pas libre :( - en tout cas qui risque de ne pas fonctionner avec le classpath GNU) ou un programme qui est fait que pour ca et qui est porte sur "tous" les systemes mais pas en java (je n'ai pas le nom en tete, j'aurais du l'evoquer ici :( )j'ai pose la question a un prof - il m'a dit qu'il avait deja pose la colle a des etudiants (master2 probablement) et aucun n'avait trouve une reponse satisfaisante. Il m'a suggere quelques pistes, /proc/stat netre autres. Le registre zindoze mais il parait qu'il n'est pas mis a jour en tant reel, alors comment unifier les resultats ?
-
Nicolas Le Scouarnec wrote:
Installer cygwin ? Tu auras alors la commande uptime comme sur tous les
autres unixes.
Il est tres probable que les utilisateurs de l'application ait cygwin
mais je ne peux pas considerer ca comme acquis. quitte a etre oblige
d'installer une usine a gaz pour avoir une mesure unifiee de la charge
du ou des CPU du systeme hote autant installer ce que propose TestMan
(pure java, mais pas libre :( - en tout cas qui risque de ne pas
fonctionner avec le classpath GNU) ou un programme qui est fait que pour
ca et qui est porte sur "tous" les systemes mais pas en java (je n'ai
pas le nom en tete, j'aurais du l'evoquer ici :( )j'ai pose la question
a un prof - il m'a dit qu'il avait deja pose la colle a des etudiants
(master2 probablement) et aucun n'avait trouve une reponse
satisfaisante. Il m'a suggere quelques pistes, /proc/stat netre autres.
Le registre zindoze mais il parait qu'il n'est pas mis a jour en tant
reel, alors comment unifier les resultats ?
Installer cygwin ? Tu auras alors la commande uptime comme sur tous les autres unixes.
Il est tres probable que les utilisateurs de l'application ait cygwin mais je ne peux pas considerer ca comme acquis. quitte a etre oblige d'installer une usine a gaz pour avoir une mesure unifiee de la charge du ou des CPU du systeme hote autant installer ce que propose TestMan (pure java, mais pas libre :( - en tout cas qui risque de ne pas fonctionner avec le classpath GNU) ou un programme qui est fait que pour ca et qui est porte sur "tous" les systemes mais pas en java (je n'ai pas le nom en tete, j'aurais du l'evoquer ici :( )j'ai pose la question a un prof - il m'a dit qu'il avait deja pose la colle a des etudiants (master2 probablement) et aucun n'avait trouve une reponse satisfaisante. Il m'a suggere quelques pistes, /proc/stat netre autres. Le registre zindoze mais il parait qu'il n'est pas mis a jour en tant reel, alors comment unifier les resultats ?
-
rp
Yves Lambert a couché sur son écran :
ben ça me ferai gagner du temps. ça n'est jamais que 1% de mon appli au pire je peux récupérer le résultat d'uptime, ça donne déjà une bonne indication mais là pareil si uptime est implanté sur 95% de *ixes je ne connais pas l'équivalent sous windoze..
-- Romain PETIT http://cerbermail.com/?O16kfXOFcq (cliquez sur le lien ci-dessus pour me contacter en privé)
Yves Lambert a couché sur son écran :
ben ça me ferai gagner du temps. ça n'est jamais que 1% de mon appli
au pire je peux récupérer le résultat d'uptime, ça donne déjà une bonne
indication mais là pareil si uptime est implanté sur 95% de *ixes je ne
connais pas l'équivalent sous windoze..
ben ça me ferai gagner du temps. ça n'est jamais que 1% de mon appli au pire je peux récupérer le résultat d'uptime, ça donne déjà une bonne indication mais là pareil si uptime est implanté sur 95% de *ixes je ne connais pas l'équivalent sous windoze..
-- Romain PETIT http://cerbermail.com/?O16kfXOFcq (cliquez sur le lien ci-dessus pour me contacter en privé)
lhabert
Nicolas George :
Non.
Plus précisément, chaque OS a sa bidouille à lui. Pour parler de ce que je connais, sous freebsd, il y a sysctl qui peut donner pas mal d'info, et sous solaris, il y a prtconf et sans doute quelques autres.
Nicolas George :
Non.
Plus précisément, chaque OS a sa bidouille à lui. Pour parler de ce que je
connais, sous freebsd, il y a sysctl qui peut donner pas mal d'info, et sous
solaris, il y a prtconf et sans doute quelques autres.
Plus précisément, chaque OS a sa bidouille à lui. Pour parler de ce que je connais, sous freebsd, il y a sysctl qui peut donner pas mal d'info, et sous solaris, il y a prtconf et sans doute quelques autres.
TestMan
Bonjour,
TestMan wrote: <...>
Le risque d'utiliser le 1.5 ou + c'est que le programme risque de ne *jamais* pouvoir tourner avec un JVM libre - probleme de brevets de licence Sun assez tordue etc. mais bon, ca c'est une limite que /je/ m'impose...
Le fait que tel ou tel projet opensource (VM dérivée de classpath ou encore Apache Harmony) ne puisse pas suivre le rythme des évolutions de la spec n'est plus maintenant qu'un problème de resource allouées à ces projets. Pourquoi ne pas commencer à demander à la FSF pourquoi classpath par exemple dispose de si peu de fonds par rapport à l'aspect "clé" du projet pour permettre à une pléthore de projets libres de fonctionner sur une base intégralement libre ? Mais l'opinion de RMS ouvertement anti-Java n'a "bien sur" rien a y voir ;-)
Au passage, il faut rapeller qu'il est complètement possible de refaire une VM en opensource et de pouvoir aposer le logo "compatible Java" à condition de passer le test de compatibilité (TCK) de plus si l'on est une organisation (comme la FSF ou Apache au hazard) on peut obtenir du JCP l'ensemble des TCK et RI sans contre-parties, et l'on est libre par exemple d'exploiter le RI ou non (dans le cas de la GPL il semble que seul l'utilisation d'un TCK soit envisageable pour des raisons légales).
Pour ce qui est des brevets possédés par Sun (ou par les autres membres des JSR), il me semble que la politique avait été clarifiée il y a quelques années déjà : si vous avez passez le TCK conformément au JCP vous êtes justement protégé car les participants des JSR rétrocèdent leur droits éventuels. Pour les autres, tant que vous n'apposez pas de logo "compatible Java" ou "compatible JSR XXX" vous n'avez pas plus de soucis particuliers à vous faire que pour du code classique.
Perso, je pense que le RI du JDK (la JVM de Sun en clair) ne devrait pas tarder à passer en CDDL (je suis super positif par nature). Celà ne résoudra pas les problèmes d'incompatibilité avec la GPL ni même n'altèrera le choix de RMS mais permettra de contribuer plus facilement au RI ...
A+ TM
Bonjour,
TestMan wrote:
<...>
Le risque d'utiliser le 1.5 ou + c'est que le programme risque de ne
*jamais* pouvoir tourner avec un JVM libre - probleme de brevets de
licence Sun assez tordue etc. mais bon, ca c'est une limite que /je/
m'impose...
Le fait que tel ou tel projet opensource (VM dérivée de classpath ou
encore Apache Harmony) ne puisse pas suivre le rythme des évolutions de
la spec n'est plus maintenant qu'un problème de resource allouées à ces
projets. Pourquoi ne pas commencer à demander à la FSF pourquoi
classpath par exemple dispose de si peu de fonds par rapport à l'aspect
"clé" du projet pour permettre à une pléthore de projets libres de
fonctionner sur une base intégralement libre ? Mais l'opinion de RMS
ouvertement anti-Java n'a "bien sur" rien a y voir ;-)
Au passage, il faut rapeller qu'il est complètement possible de refaire
une VM en opensource et de pouvoir aposer le logo "compatible Java" à
condition de passer le test de compatibilité (TCK) de plus si l'on est
une organisation (comme la FSF ou Apache au hazard) on peut obtenir du
JCP l'ensemble des TCK et RI sans contre-parties, et l'on est libre par
exemple d'exploiter le RI ou non (dans le cas de la GPL il semble que
seul l'utilisation d'un TCK soit envisageable pour des raisons légales).
Pour ce qui est des brevets possédés par Sun (ou par les autres membres
des JSR), il me semble que la politique avait été clarifiée il y a
quelques années déjà : si vous avez passez le TCK conformément au JCP
vous êtes justement protégé car les participants des JSR rétrocèdent
leur droits éventuels. Pour les autres, tant que vous n'apposez pas de
logo "compatible Java" ou "compatible JSR XXX" vous n'avez pas plus de
soucis particuliers à vous faire que pour du code classique.
Perso, je pense que le RI du JDK (la JVM de Sun en clair) ne devrait pas
tarder à passer en CDDL (je suis super positif par nature). Celà ne
résoudra pas les problèmes d'incompatibilité avec la GPL ni même
n'altèrera le choix de RMS mais permettra de contribuer plus facilement
au RI ...
Le risque d'utiliser le 1.5 ou + c'est que le programme risque de ne *jamais* pouvoir tourner avec un JVM libre - probleme de brevets de licence Sun assez tordue etc. mais bon, ca c'est une limite que /je/ m'impose...
Le fait que tel ou tel projet opensource (VM dérivée de classpath ou encore Apache Harmony) ne puisse pas suivre le rythme des évolutions de la spec n'est plus maintenant qu'un problème de resource allouées à ces projets. Pourquoi ne pas commencer à demander à la FSF pourquoi classpath par exemple dispose de si peu de fonds par rapport à l'aspect "clé" du projet pour permettre à une pléthore de projets libres de fonctionner sur une base intégralement libre ? Mais l'opinion de RMS ouvertement anti-Java n'a "bien sur" rien a y voir ;-)
Au passage, il faut rapeller qu'il est complètement possible de refaire une VM en opensource et de pouvoir aposer le logo "compatible Java" à condition de passer le test de compatibilité (TCK) de plus si l'on est une organisation (comme la FSF ou Apache au hazard) on peut obtenir du JCP l'ensemble des TCK et RI sans contre-parties, et l'on est libre par exemple d'exploiter le RI ou non (dans le cas de la GPL il semble que seul l'utilisation d'un TCK soit envisageable pour des raisons légales).
Pour ce qui est des brevets possédés par Sun (ou par les autres membres des JSR), il me semble que la politique avait été clarifiée il y a quelques années déjà : si vous avez passez le TCK conformément au JCP vous êtes justement protégé car les participants des JSR rétrocèdent leur droits éventuels. Pour les autres, tant que vous n'apposez pas de logo "compatible Java" ou "compatible JSR XXX" vous n'avez pas plus de soucis particuliers à vous faire que pour du code classique.
Perso, je pense que le RI du JDK (la JVM de Sun en clair) ne devrait pas tarder à passer en CDDL (je suis super positif par nature). Celà ne résoudra pas les problèmes d'incompatibilité avec la GPL ni même n'altèrera le choix de RMS mais permettra de contribuer plus facilement au RI ...
