Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Un coprocesseur pour accélérer les ramasse-miettes
On pourrait gagner un facteur 4 en temps d'exécution sur les opérations de gestion de la mémoire

Le , par dourouc05

76PARTAGES

25  0 
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.

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Aiekick
Membre extrêmement actif https://www.developpez.com
Le 09/05/2019 à 12:43
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.
4  0 
Avatar de transgohan
Expert éminent https://www.developpez.com
Le 09/05/2019 à 18:17
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.
4  0 
Avatar de NBoulfroy
Membre éclairé https://www.developpez.com
Le 09/05/2019 à 11:58
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.
3  0 
Avatar de olvini3
Nouveau membre du Club https://www.developpez.com
Le 09/05/2019 à 14:54
Citation Envoyé par Aiekick Voir le message
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.
1  0 
Avatar de Cassoulatine
Nouveau Candidat au Club https://www.developpez.com
Le 09/05/2019 à 22:17
Ce qui fera autant de silicium de moins pour le reste. Tout ça parce que gérer ses allocations mémoire c tro dur.
1  0 
Avatar de sergio_is_back
Membre expert https://www.developpez.com
Le 10/05/2019 à 11:18
Citation Envoyé par foetus Voir le message

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...
1  0 
Avatar de Neckara
Inactif https://www.developpez.com
Le 09/05/2019 à 14:08
Citation Envoyé par Aiekick Voir le message
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é) ?
0  0 
Avatar de NBoulfroy
Membre éclairé https://www.developpez.com
Le 09/05/2019 à 15:03
Citation Envoyé par olvini3 Voir le message
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é) ?
0  0 
Avatar de moustic98
Nouveau Candidat au Club https://www.developpez.com
Le 09/05/2019 à 18:07
Le GC reste toujours customisable en java :

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

Moustic
0  0 
Avatar de ijk-ref
Membre confirmé https://www.developpez.com
Le 10/05/2019 à 1:01
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.
0  0