Discussion :

[PandaConstantin01]

Bonsoir tout le monde ,
Java vs C++ est un vieux débat que moi je trouve sans aucun apport aujourd'hui. Le monde Java adopte C++ dans certains codages. Je crois que le topic du débat doit être changé. Moi particulièrement je suis lassé de mettre C++ et Java en confrontation. On gagnerait avec "Quels sont les avantages d'intégrer Java et C++ ? " .
Mes excuses pour les mots durs et vive la programmation !
Cordialement ,
- PandaConstantin01

[hegros]

Luc, désolé je ne comprends pas. C'est quoi dans l'exemple la ressource de la connexion et du verrou ?

Comment peux-tu affirmer que tu t'en moques alors que tu spécifies explicitement de les libérer?

zaventem en principe quand j'appelle une méthode close sur une ressource notamment sur un verrou c'est que c'est son rôle de relacher le fichier, il ne sera plus verrouillé sinon c'est que ce n'est pas la bonne méthode à appeler.

Pour une connexion à une base de données c'est pareil. La c'est encore plus simple parce que selon les architectures (de plus en plus 2 ou n tiers) c'est la partie serveur de base de données qui reçoit une requete close et qui se voit attribuer la responsabilité de fermer la connexion (de la libérer définitivement) donc toute tentative ultérieure ménera au mieux à un échec côté client..

[adiGuba]

Je ne comprends pas pourquoi tu tiens à faire cette distinction? Qu'est-ce qui te dérange dans le fait de considérer la mémoire en tant que ressources? Elle ne se gère pas de la même manière qu'un fichier, certes, mais lui même ne se gère pas de la même manière qu'une connexion DB, etc.

Parce que lorsqu'on utilise un GC cette distinction est importante.

Sans GC je suis d'accord avec toi : il s'agit d'une ressource qu'il faut gérer soi-même et libérer sous peine de problème en cas d'utilisation intense de la ressource (trop de fichier ouvert, plus de mémoire disponible sur le système, etc.). Bref : il faut gérer ses ressources, et donc on a besoin de pouvoir déterminer avec précision le moment exact de cette libération.


Mais puisque le GC se charge de gérer la ressource "mémoire", c'est lui qui a besoin de connaitre ce moment avec précision. Nous en tant qu'utilisateur du GC cela importe peu...



Je vais prendre un exemple extrème pour m'expliquer : une boucle qui ouvre indéfiniment un fichier :

Code Java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
	public static void openFile(String file) throws FileNotFoundException {
		new FileInputStream(file);
	}
 
 
	public static void main(String[] args) throws Exception {
		while (true) {
			openFile("/tmp/test.txt");
		}
	}

Que se passe-t-il : j'obtiens assez rapidement une erreur : "(Too many open files)"

La raison est simple et évidente : les ressources ne sont pas libéré auprès du système !




Que se passe-t-il lorsqu'on fait la même chose avec la mémoire :

Code Java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
	public static void createObject() {
		new Object();
	}
 
 
	public static void main(String[] args) throws Exception {
		while (true) {
			createObject();
		}
	}

Faire l'équivalent de ceci dans un langage sans GC va provoquer une catastrophe : chaque objet créé dynamiquement va rester en mémoire et ne sera plus libérable. Cela va faire augmenter la consommation mémoire continuellement et surcharger le système...


Avec un GC ce problème n'existe pas : bien sûr à un moment T il y aura plusieurs objets en mémoire inutilement, mais ces espaces pourront être réutilisés si besoin. Mieux : il n'y aura pas d'augmentation de l'utilisation mémoire du programme !!!


En fait il faut bien comprendre les mécanismes du GC :

• Le GC alloue à l'avance une certaine taille mémoire auprès du système (mémoire "committed"). Par défaut la taille allouée dépend de certains critères, mais en général cela doit varier entre 1 et 5Mo. Cette mémoire est ensuite utilisé par le GC pour les allocations du programme (en fait cette mémoire est découpé en plusieurs parties pour faciliter les traitements).
• Chaque allocation va donc utiliser cette mémoire pour le stockage. On distingue alors la mémoire "used" qui correspond à la mémoire réellement utilisée par le programme.
• Le GC peut faire des "minors collections", il s'agit d'un algorithme simple et rapide qui permet de "nettoyer" les objets de "courte durée de vie" de la mémoire "committed".
• Le GC peut également faire des "majors collections", qui permettent de réellement libérer tous les objets, mais qui sont nettement plus couteuse...

Que ce passe-t-il dans notre programme :

• Le programme va boucler et créer plein d'instance. Comme le GC ne libère pas de suite les objets cela va faire augmenter la mémoire "used".
• Le GC va effectuer des "minors collections" (je ne sais pas précisément quand ni sous quelle condition). Mais ceci va faire redescendre la mémoire "used", ce qui fait que la mémoire "committed" n'aura pas changé. Il n'y aura eu aucune allocation mémoire supplémentaire auprès du système...

Maintenant prenons le cas le plus intéressant : l'application a utilisée toute la mémoire "committed", ce qui fait qu'on ne peux plus alloué d'objet : le GC va alors des "minor/major" collections pour tenter de libérer de la mémoire :

• S'il arrive a en libérer suffisamment, il va alors utiliser cet espace libre pour allouer l'objet et continuer ses traitements (la taille "committed" n'aura pas changé). Dans notre exemple on pourrait se retrouver dans ce cas (le programme crée un grand nombre d'objet qui ne sont plus référencé, et qui sont donc libérable).
  
  Même si la mémoire n'est pas libéré immédiatement, elle n'empêche pas sa réutilisation...
• Dans le cas où le GC n'arrive pas à libérer suffisamment de mémoire (ce qui signifie que les objets ne sont pas libérables, et donc toujours référencés par l'application), alors le GC va faire une allocation mémoire auprès du système pour augmenter la taille de la mémoire "committed" et pouvoir continuer à travailler...
  
  La taille mémoire alloué va alors augmenté, mais cela correspond à une utilisation de l'application.

Bref : on n'a pas besoin de connaitre avec précision le moment de libération de la mémoire, car ceci ne nous empêche pas de réutiliser cet espace mémoire
Et tout ceci est géré par le GC


Je précise que j'ai donné des exemples en Java, mais cela concerne n'importe quel langage avec un GC.

J'espère que ce n'est pas trop confus...


a++

[Luc Hermitte]

connection.close() et verrou.close() sont deux libérations de ressource.
A partir du moment où tu les réalises, c'est que tu ne t'en moques pas.

[adiGuba]

connection.close() et verrou.close() sont deux libérations de ressource.
A partir du moment où tu les réalises, c'est que tu ne t'en moques pas.

On libère les ressources (fichier, connexion BD, socket, etc.) mais pas la mémoire (c'est le GC qui fait cela)

a++

[hegros]

Du point de vue du programme qui utilise la connexion et le verrou les ressources sont bien libérées et inutilisable puisqu'elles sont initialisées à null


Du point de vue de la jvm maintenant je n'ai pas fouiné. Il y a évidemment des risques puisque si l'algorithme de libération d'objet foire il reste d'une certaine façon utilisable mais avec une architecture n-tiers fonctionnellement la connexion sera fermée (sauf si encore l'algorithme de libération de la ressource foire au niveau du serveur)

De mon point de vue c'est un bon compromis, il est possible encore de réécrire un gc ou une jvm de toute façon sur des projets moyens ou grands en c++ il faut de toute façon s'occuper de la mémoire on n'a pas le choix

[blbird]

La seule chose qu'on ait à gérer en Java concernant la mémoire, c'est pour des projets spécifiques où celle-ci est limitée (ou si on sait qu'on va en utiliser beaucoup). Il faut alors veiller à ne pas en utiliser plus que de raison, et à aider le GC à faire son travail au plus vite.

Mais dans la plupart des cas, en Java, tu ne te préoccupes pas de la gestion de la mémoire.

[kedare]

On libère les ressources (fichier, connexion BD, socket, etc.) mais pas la mémoire (c'est le GC qui fait cela)

a++

c'est pas specifique a java ca, pratiquement tout les langages a GC font ca, j'ai déja eu une mauvaise experience avec python (un one liner qui fait tout planter ;p)

[hegros]

c'est pas specifique a java ca, pratiquement tout les langages a GC font ca, j'ai déja eu une mauvaise experience avec python (un one liner qui fait tout planter ;p)

C'est un débat C++ vs Java. Le GC n'est qu'un point parmi d'autres mais marque déja une différence avec le C++ en fait cela dépend duquel.

Pour dire la vérité le GC ne me sert qu'a ramasser les miettes pas plus !

[adiGuba]

c'est pas specifique a java ca, pratiquement tout les langages a GC font ca, j'ai déja eu une mauvaise experience avec python (un one liner qui fait tout planter ;p)

Comme je l'ai dit dans mon précédent message :

Je précise que j'ai donné des exemples en Java, mais cela concerne n'importe quel langage avec un GC.

a++

[jpouly]

Histoire de troller un peu plus,
je n'ai jamais compris pourquoi on compare Java à C++.

Pour moi, le C++ c'est fait pour le système, le calcule brutale, bref tout ce qui nécéssite de la puissance de traitement.

Java, au contraire, est plutot adapter pour les développements lourds, avec des bases de données et des interfaces utilisateurs complexes.

Je comparerais volontier C# et java, mais pas C++ et java.

Leur seul point commun, c'est peut être la ribanbelle de frameworks, librairies, etc... qui fait qu'on est un peu perdu quand on se lance

a++

[rakakabe]

Histoire de troller un peu plus,
je n'ai jamais compris pourquoi on compare Java à C++.

+1
Oui mais tout le monde aime troller car "Pas touche" a mon langage prefere.

[Uther]

Histoire de troller un peu plus,
je n'ai jamais compris pourquoi on compare Java à C++.

Pour moi, le C++ c'est fait pour le système, le calcule brutale, bref tout ce qui nécéssite de la puissance de traitement.

Java, au contraire, est plutot adapter pour les développements lourds, avec des bases de données et des interfaces utilisateurs complexes.

Je comparerais volontier C# et java, mais pas C++ et java.

Leur seul point commun, c'est peut être la ribanbelle de frameworks, librairies, etc... qui fait qu'on est un peu perdu quand on se lance

a++

Je ne suis pas tout a fait d'accord.

C'est vrai que Java n'est généralement pas adapté pour de la programmation système, et je n'envisage pas d'utiliser C++ pour un serveur d'application. Pourtant, il y a des tas d'applications ou la question Java ou C++ est très pertinente.

Si tu fait du client lourd avec Swing et Qt par exemple la différence entre les deux est déjà beaucoup moins flagrante.

[Mat.M]

Les utilisateurs détestent Java

Parmi les choses qui vous enragent dans un PC, à combien évalueriez-vous les «Mises à jour Java» sur une échelle de 1 à 10 ?

Personnellement, ce n'est plus à 10 sur 10 puisque j'ai réglé le problème. J'ai suivi la courte démarche que je vous explique plus loin et je ne me fais plus achaler par cette désagréable et nuisible engeance.

Nuisible ? Si on ne fait pas gaffe, elle nous installe la barre d'outils Yahoo. Normalement je fais disparaître de mon système tout ce qui tente de me rentrer un polluriel dans la gorge, mais je ne le peux avec Java. Ce langage de Sun Microsystems est essentiel au bon fonctionnement de certaines applications.

http://blogues.cyberpresse.ca/techna...ais/?p=1004642

Au moins avec un programme fait en C++ on n'est pas enquiquinné

Le programmeur il ne pense jamais à l'utilisateur

[Garulfo]

Histoire de troller un peu plus,
je n'ai jamais compris pourquoi on compare Java à C++.

Pour moi, le C++ c'est fait pour le système, le calcule brutale, bref tout ce qui nécéssite de la puissance de traitement.

Java, au contraire, est plutot adapter pour les développements lourds, avec des bases de données et des interfaces utilisateurs complexes.[...]

Et tu as tort. Java et C++ ont suffisamment évolués pour pouvoir marcher sur les plates bandes de l'autre.

[Alp]

Et tu as tort. Java et C++ ont suffisamment évolués pour pouvoir marcher sur les plates bandes de l'autre.

+1. Y'a même des frameworks web pour C++ et des outils bas niveau pour Java.
On peut ne plus se soucier de la mémoire en C++.
etc...

Faut se mettre à l'heure, on n'est plus il y a 10 ans
(oui, ça doit faire 5 fois que je le dis depuis le début de ce sujet)

[Tommy31]

+1. Y'a même des frameworks web pour C++ et des outils bas niveau pour Java.
On peut ne plus se soucier de la mémoire en C++.

Certes, mais sont-ils équivalents (en performance, notoriété, documentation, facilité de mise en oeuvre...) ? Ca m'intéresserait d'avoir un état de l'art en la matière.

[hugo123]

Les utilisateurs détestent Java

http://blogues.cyberpresse.ca/techna...ais/?p=1004642

Au moins avec un programme fait en C++ on n'est pas enquiquinné

Le programmeur il ne pense jamais à l'utilisateur

faut-il vraiment aborder ce sujet ? Parlons dans ce cas des conflits de dll, dll non trouvés, incompatibilité des versions-de-je-ne-sais-quoi sur mon poste (installeur machin, framework bidule, librairies truc).

[gorgonite]

faut-il vraiment aborder ce sujet ? Parlons dans ce cas des conflits de dll, dll non trouvés, incompatibilité des versions-de-je-ne-sais-quoi sur mon poste (installeur machin, framework bidule, librairies truc).

ben parlons des jar manquants, etc
parlons des API non standards entre les différentes VM, etc



STOP aux trolls

[Uther]

ben parlons des jar manquants, etc
parlons des API non standards entre les différentes VM, etc

Il faut quand même admettre que java(sauf java me) s'en tire globalement bien mieux sur ce point car il a été bien plus strictement spécifié dès le début. Alors que les compilateur C se sont mis au standards(qui sont pourtant pas tout neuf) que très récemment.