Discussion :

[dourouc05]

Un reproche régulièrement fait aux langages comme Java ou C# est que la gestion de la mémoire n'est pas effectuée par le programmeur, contrairement au C ou au C++. Le développement est beaucoup plus simple, au prix de l'ajout d'une pièce très lourde à l'exécution : un ramasse-miettes. Celui-ci cherche régulièrement les bouts de mémoire qui peuvent être libérés, car plus utilisés, sans quoi le programme utilise de plus en plus de mémoire et finit par bloquer l'ordinateur. Selon certaines estimations, un programme peut passer jusqu'à une dizaine de pour cent de son temps d'exécution sur le ramasse-miettes ! Certes, cette estimation ne tient pas compte du temps à l'exécution que prendrait une gestion manuelle de la mémoire, mais le chiffre reste intéressant.

Que peut-on faire pour améliorer la situation ? Les processeurs actuels ne sont pas vraiment prévus pour les opérations de nettoyage de la mémoire. Une idée est d'ajouter un petit coprocesseur qui exécuterait uniquement le ramasse-miettes. Ce dernier pourrait n'utiliser que peu de transistors et d'énergie, mais aussi s'exécuter en parallèle. Il pourrait aussi être intégré au plus proche de la mémoire, ce qui diminuerait la consommation d'énergie en transfert de données.

Selon les tests effectués (un tel accélérateur intégré à un processeur RocketChip RISC-V), une telle puce pourrait être utilisée pour des ramasse-miettes bloquants ou non. En l'utilisant dans une machine virtuelle Java (JikesRVM), il serait possible d'accélérer les opérations de gestion de la mémoire d'un facteur quatre ! La réduction de consommation d'énergie, avec ce prototype, est de quinze pour cent, en utilisant moins de vingt pour cent de la surface d'un cœur de calcul.

Voir aussi : A Hardware Accelerator for Tracing Garbage Collection.

Source : For Better Computing, Liberate CPUs From Garbage Collection.

[NBoulfroy]

Il y a peut être une solution hardware à ce problème qui s'accentue mais il faut aussi continuer le travail d'optimisation du ramasse-miette de la part des éditeurs pour ainsi limiter le problème.

[Aiekick]

moi ce que je trouvait le plus dommageable avec les ramasses miette c# et java, c'est qu'il se déclenchent quand ils veulent.

l'utilisateur n'a aucun contrôle sur CA. et pourtant il y a des moment ou c'est pas le moment.

[Neckara]

moi ce que je trouvait le plus dommageable avec les ramasses miette c# et java, c'est qu'il se déclenchent quand ils veulent.

l'utilisateur n'a aucun contrôle sur CA. et pourtant il y a des moment ou c'est pas le moment.

Cela fait longtemps que je n'ai fais ni Java ni C#, mais n'y a-t-il pas des fonctions du type gc.collect() ou de la définition de code atomique (dans lequel le gc ne sera pas appelé) ?

[olvini3]

moi ce que je trouvait le plus dommageable avec les ramasses miette c# et java, c'est qu'il se déclenchent quand ils veulent.

l'utilisateur n'a aucun contrôle sur CA. et pourtant il y a des moment ou c'est pas le moment.

On peut plus ou moins contrôler le GC en C# avec GC.Collect(), par exemple.
On peut aussi empêcher le GC d'agir pendant sur une partie du code avec "GC.TryStartNoGCRegion()" et "GC.EndNoGCRegion()" bien que je n'ai jamais testé ces méthodes.

[NBoulfroy]

On peut plus ou moins contrôler le GC en C# avec GC.Collect(), par exemple.
On peut aussi empêcher le GC d'agir pendant sur une partie du code avec "GC.TryStartNoGCRegion()" et "GC.EndNoGCRegion()" bien que je n'ai jamais testé ces méthodes.

Cela ne tue pas un des intérêts des langages comme le C# d'empêcher le garbage collector de faire sa vie (je parle en terme de technicité) ?

[moustic98]

Le GC reste toujours customisable en java :

https://www.cubrid.org/blog/how-to-t...ge-collection/

Moustic

[transgohan]

J'ai deux visions pour ma part.

La première qui se dit qu'un ramasse miette c'est une bêtise... A trop vouloir décharger de la compétence du développeur on se retrouve avec des usines à gaz.
Et là je vois cela comme : comment peut-on optimiser notre usine à gaz.

La seconde qui se dit qu'un ramasse miette qui se lance n'importe quand c'est pas vraiment tiptop niveau gestion du process et des ressources (même si on ne gère déjà pas une partie des ressources : mémoire).
De ce fait un co-processeur pour lui dédier la charge d'exécution du ramasse miette est une très bonne idée.
Cela rejoint tout à fait le rôle des coprocesseurs de communication pour gérer les uarts et autre par exemple.

[Cassoulatine]

Ce qui fera autant de silicium de moins pour le reste. Tout ça parce que gérer ses allocations mémoire c tro dur.

[ijk-ref]

Si ce coprocesseur apporterait un réel avantage pour libérer de la mémoire… même pour des langages sans ramasse-miette… alors pourquoi pas.

Cependant il serait aussi judicieux des faire évoluer les langages (tel C# ou C++) pour permettre une gestion de la mémoire plus poussée et plus sécurisée à l'instar de Rust.

[foetus]

Cependant il serait aussi judicieux des faire évoluer les langages (tel C# ou C++) pour permettre une gestion de la mémoire plus pousser et plus sécurisé à l'instar de Rust.

Le projet Midori de Microsoft peut/ pouvait rendre obsolète cette approche

En gros, un processus c'est une boîte noire avec son code, sa mémoire.
Si un processus veut utiliser des resources ou communiquer avec un service/ processus/ dlls/ ..., il passe par un système de contrat.
Et enfin, il y avait une histoire de langages/ codes sûrs (comme le C#) et ceux pas sûrs (comme le C/ C++). Et les codes sûrs tournent en ring 1 et ceux pas sûrs en ring utilisateur

[sergio_is_back]

En gros, un processus c'est une boîte noire avec son code, sa mémoire.
Si un processus veut utiliser des resources ou communiquer avec un service/ processus/ dlls/ ..., il passe par un système de contrat.

Je vois pas trop le rapport avec le garbage collector... Et en développement quand un processus devient une boite noire on commence à avoir des problèmes...

[Patrick75015]

Ne pas faire le ménage - Ne pas vider la poubelle

=> embaucher une personne pour faire le ménage @ home, ça coûte cher

=> utiliser une usine à gaz en informatique, pas gratuit non plus...

/troll on
les informaticiens ne font pas le ménage chez eux?
pourquoi le faire en informatique?
/troll off

[Aiekick]

Cela fait longtemps que je n'ai fais ni Java ni C#, mais n'y a-t-il pas des fonctions du type gc.collect() ou de la définition de code atomique (dans lequel le gc ne sera pas appelé) ?

c'est cool, je ne savais pas que ça avait été ajouté. je vais peu être re regardé ca de pres du coup

[foetus]

Je vois pas trop le rapport avec le garbage collector... Et en développement quand un processus devient une boite noire on commence à avoir des problèmes...

Le rapport doit être extrapolé

Avec ce projet, c'est le compilateur qui faisait des vérifications systèmes (par exemple type et taille des données à échanger lors d'un contrat). D'où la notion de code sûr/ code pas sûr.
Et donc un code pas sûr été [+ ou -] virtualisé en ring utilisateur. Ceci permet la rétrocompatibilité ... au prix éventuellement de la vitesse.
Mais si le code est sûr, on peut penser que c'est le système d'exploitation qui fait office de ramasse-miettes. On a plus besoin de machine virtuelle ... et de toute manière le logiciel devient trop dépend du système d'exploitation pour être portable.

[mopakarim]

Le rapport doit être extrapolé

Avec ce projet, c'est le compilateur qui faisait des vérifications systèmes (par exemple type et taille des données à échanger lors d'un contrat). D'où la notion de code sûr/ code pas sûr.
Et donc un code pas sûr été [+ ou -] virtualisé en ring utilisateur. Ceci permet la rétrocompatibilité ... au prix éventuellement de la vitesse.
Mais si le code est sûr, on peut penser que c'est le système d'exploitation qui fait office de ramasse-miettes. On a plus besoin de machine virtuelle ... et de toute manière le logiciel devient trop dépend du système d'exploitation Youjizz Pornhub Tubegalorepour être portable.

Cela fait longtemps que je n'ai fais ni Java ni C#, mais n'y a-t-il pas des fonctions du type gc.collect() ou de la définition de code atomique (dans lequel le gc ne sera pas appelé) ?

[gangsoleil]

Bonjour,

n'y a-t-il pas des fonctions du type gc.collect()

Le comportement peut avoir changé depuis l'époque, mais en java ce type d'appel (system.gc() de mémoire) ne te promet rien sur l'appel réel du GC, simplement que le système va essayer de le faire -- la nuance est assez grande.


Sinon, pour revenir à la news, ce type d'amélioration revient, de mon point de vue, à dire "vous n'avez pas assez de performances ? Changez de machine" -- phrase que j'ai souvent entendue. Je sais qu'un GC est quelque chose de complexe, mais je serai plus pour chercher à l'optimiser -- et aussi optimiser le code -- plutôt que d'ajouter un processeur à côté qui fait ce traitement plus vite.

Tout ceci sans prendre en compte les problèmes d'implémentation que ça demande, et les soucis de sécurité.