Developpez.com - Rubrique Hardware

Le Club des Développeurs et IT Pro

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 2019-05-09 04:08:59, par dourouc05, Responsable Qt & Livres
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.
  Discussion forum
16 commentaires
  • Aiekick
    Membre extrêmement actif
    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.
    le 09/05/2019 à 12:43
  • transgohan
    Expert éminent
    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.
    le 09/05/2019 à 18:17
  • NBoulfroy
    Membre éclairé
    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.
    le 09/05/2019 à 11:58
  • olvini3
    Nouveau membre du Club
    Envoyé par 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.
    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.
    le 09/05/2019 à 14:54
  • Cassoulatine
    Nouveau Candidat au Club
    Ce qui fera autant de silicium de moins pour le reste. Tout ça parce que gérer ses allocations mémoire c tro dur.
    le 09/05/2019 à 22:17
  • sergio_is_back
    Expert confirmé
    Envoyé par foetus

    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...
    le 10/05/2019 à 11:18
  • Neckara
    Inactif
    Envoyé par 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.
    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é) ?
    le 09/05/2019 à 14:08
  • NBoulfroy
    Membre éclairé
    Envoyé par olvini3
    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é) ?
    le 09/05/2019 à 15:03
  • moustic98
    Membre à l'essai
    Le GC reste toujours customisable en java :

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

    Moustic
    le 09/05/2019 à 18:07
  • ijk-ref
    Membre éclairé
    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.
    le 10/05/2019 à 1:01
  Poster une réponse