Jolt sort vos programmes des boucles infinies
Ne jamais voir son ordinateur planter, le rêve de tout utilisateur. Beaucoup d'efforts ont été déployés au fil des ans pour que ce rêve devienne réalité, comme récemment l'isolation des processus dans les navigateurs. Une nouvelle voie est explorée par des chercheurs du MIT qui ont conçu Jolt. Jolt surveille l'exécution de tout autre programme et le débloque si jamais il se lance dans une boucle infinie.
Jolt a vu le jour quand un de ces créateurs était bloqué dans la rédaction d'un document par Word qui plantait. A l'aide d'un outil de débuggage, l'homme a constaté que Word s'enfermait dans une boucle. En l'en faisant sortir manuellement, le chercheur a débloqué Word et a pu finir son travail.
Jolt fonctionne sur le même principe : il compare l'état du programme en mémoire au début de chaque itération d'une boucle. Si rien ne change, Jolt interrompt la boucle pour que le reste du programme s'exécute. Ce fonctionnement impose une grosse contrainte : il faut recompiler chaque programme pour ajouter des appels de fonction à chaque démarrage et fin de chaque boucle et pour indiquer à quel endroit l'exécution doit reprendre en cas de blocage.
Mais une fois ceci fait, Jolt est efficace. Ses créateurs l'ont testé et dans 7 situations sur 8 Jolt a trouvé la boucle infinie et a décoincé le programme qui a fini son exécution de manière normale sauf pour la partie concernée par la boucle fautive. Dans 2 des 8 cas, le résultat fourni par Jolt était même identique au résultat d'une version patchée du programme. La surcharge de calcul due à Jolt variait entre 0,5 et 8,6 %. Les chercheurs travaillent dorénavant sur Bolt, un Jolt libéré de la contrainte de la recompilation. Et l'on se reprend à rêver.
- Developpement,
- jolt ,
- infinite ,
- loop
- Intel Ultrabook : ça se précise
- Les GPU NVIDIA Kepler arriveront fin 2011
- SilverStone ST50NF : 500W en fanless
- Google préfèrerait l'OMAP 4 pour Android 4.0
- Asus F1A75-I Deluxe : du FM1 en mini-ITX
- Adieu WiFi : un réseau à LED atteint 800 Mb/s
- Tom’s Guide : les nouveautés de Mac OS X Lion
- eBay achète 100 To de mémoire flash
- Le Tegra 3 sortira à l'automne
- Le Z-Drive R4 d’OCZ flashé à 2800 Mo/s
- La plus grosse attaque pirate de tous les temps
- Nostalgeek 2001 (30) : DirectX 9, AYHJAR
- Les meilleures configurations d'août
- Toshiba Qosmio F755 : un 15,6" 3D sans lunettes
- Révélations de Microsoft sur l'affaire Novell : Google voulait faire bande à part
- Linus Torvalds déteste Gnome 3
- Asus (re)tente Linux sur les Eee PC en France
- Quatre contrôleurs pour quatre ports USB 3.0






Lave plus blanc que blanc
8 situations sur 7, trop fort !!
En plus si les plantages d'applies n'étaient dus qu'à des boucles infinies, ça serait simple...
Hélas, ce n'est pas avec ce genre de programme que l'on va améliorer la qualité global d'un produit.
Un programme qui plante impose aux développeurs de faire du support (mise à jour) le plus rapidement possible suivant la gravité, et donc de corriger le problème. Si un système tel que Jolt se retrouve intégré partout, on ne verra plus de problème sauf un message abscons (plantage 0x00101010) et les patchs mettront plus de temps à sortir, et le code sera globalement plus instable mais on s'en fiche... jusqu'au moment ou l'instabilité détruit le travail que l'on a produit (le document word), et ou le débogage sera d'autant plus difficile (c'est quel plantage qui a cassé le document ?).
Bref, Jolt ne sera utile qu'en cas de débogage, et encore...
Lave plus blanc que blanc
8 situations sur 7, trop fort !!
Fait trop chaud pour travailler...
Y'a pas grand chose d'extraordinaire... c'est une super mauvaise idée, ça résout aucun problème, et surtout ça va pas forcément débloquer l'appli. En fait, ça peut même entraîner sa fermeture pure et simple. Voire pire : si une appli plante, c'est pas pour faire chier, c'est aussi parce qu'elle ne peut plus garantir son fonctionnement normal, et que pour éviter des actions aléatoires, on l'arrête.
J'ai encore vu ça y'a quelques minutes sur une appli que je développe. Elle plante pendant la sauvegarde, donc j'ai viré le truc qui plante à savoir une boucle infinie, histoire de continuer à bosser dessus. Bah résultat, au lieu de planter pendant la sauvegarde, ça la réussit sauf que ça écrit un fichier vide. Donc en gros si ça plante, on perd une partie du boulot, mais si ça continue, hé bah on perd tout...
Sinon y'a déjà des tas de gens qui mettent en place des procédés de ce genre. On lance un thread, on suit son exécution, et si on voit que ça prend trop de temps, qu'il fournit pas le travail qu'il est sensé fournir... on l'arrête. Ou on se sert du watchdog. Mais quoi qu'il en soit, c'est pas magique un programme, on peut pas se permettre de faire des choses comme ça.
Fait trop chaud pour travailler...
Tu veux un pulco citron ?
Ca marcherait sur des pilotes de cartes graphiques par exemples? Car la mienne à la facheuse tendance à s'enfermer dans des boucles infinies et W7 (ou VPU Recover sous XP) le redémarre sans cesse.
Sa me rappele " Norton CrashGuard " qui empechait les programems de planter masi qui lui fesait GELER completement Windows
... une vraie daube
http://www.symantec.com/about/news [...] 9960930_01
et le mot "norton" ne t'avait pas mis la puce à l'oreille?
c etais pas trop pourri norton a l epoque !!!
7 situations sur 8 Jolt
sous x11 il y avait une grosse boucle infinie (while (1)) afin d'attendre/traiter les événements claviers/souris. Jolt risque fort de porter préjudice à bien des "vraies" boucles infinies !
Beurk... Une courtilière sur la langue, tu parles d'un beug !
zaxxon123 > sources?
Ils feraient mieux de réfléchir à une méthodologie pour justement éviter ce genre de bogues, et non patcher en dynamique du code inconnu...Je vois bien le résultat sur un A320 qui entre dans une boucle infinie !!!
N'étant pas un programmeur (quelques scripts VBA par ci/par là).
Je me demande si les programmeurs ne font ils pas moins d'effort ?
Il fut un temps où les PC étaient limités en mémoire 640Ko RAM et en espace disque, ils devait faire des prouesses techniques/imaginations/... pour que leurs programmes tournent bien.
Maintenant, le programme tourne pas ou tourne moins bien => acheter + de RAM ou acheter un disque plus grand ou acheter un CPU/GPU plus puissant ou tout à la fois
@brutus--OS > il y a malheureusement beaucoup de développeurs qui pensent qu'avec les derniers matériels ou dernières versions de dotNet/Java, on n'a plus à ce préoccuper des perfs...
Cela fait plus de 14 ans, que je travaille en informatique, la performance est toujours une problématique pour beaucoup d'applications. Certains architectes ou développeurs "pondent" des m.rd.es immondes (et en sont fiers) et laissent les équipes d'exploitation dans une situation où l'application est trop lente ou prend trop de ressources systèmes. Résultat, c'est les utilisateurs qui trinquent..
Sinon, le développement est une activité difficile dans le sens où malgré les plus grandes précautions, il y a toujours des bugs. Et juste un peu mot pour la fin, la qualité d'un logiciel (dont la fiabilité et la performance) n'arrive jamais par hasard. Il faut qu'il y ait une volonté et du budget pour améliorer significativement la qualité d'un logiciel quelqu'il soit.
Quand on voit qu'aujourd'hui faut un PC de compet' pour surfer sur le ouaibe et afficher des pages dont la complexité et la réactivité dépassent même pas un jeu sur SNES, on se rend qu'il y a effectivement un problème de perfs aujourd'hui...