Journal L'allocation mémoire et les langages fonctionnels

Posté par  .
Étiquettes : aucune
0
3
mar.
2004
Imaginons un langage avec un garbage collector (style ocaml) et un programme de porc du style :

{
variables_globales_d_init qui font 50 Mo ;
variables_pour_la_suite qui font 50 Mo ;
mon code d'init qui utilise les variables d'init ;
mon code pour la suite qui utilise plus les variables d'init ;
}

Je me dis que les variables utilisées pour l'init vont jamais être libérées, à moins que le compilateur ait fait une analyse statique du code pour voir à quel moment les variables cessaient d'être utilisées. Si y'a pas d'analyse statique, alors je me trimbale avec un programme qui me prend 100 Mo au lieu de 50 Mo. Ou alors je peux désalouer la ram à la main en cassant la référence vers mais variables d'init, i.e. je me fais de la gestion mémoire à la mimine, ce qui limite largement l'intérêt du garbage collector :)

  • # Re: L'allocation mémoire et les langages fonctionnels

    Posté par  (site web personnel) . Évalué à 5.

    C'est pas specialement lié aux langages fonctionnels.
    Si en java tu gardes les references vers des trucs inutiles c'est pareil.

  • # Re: L'allocation mémoire et les langages fonctionnels

    Posté par  . Évalué à 1.

    ça ne répond complètement pas à ta question, car le travail n'est pas fait automatiquement par le compilo, mais c'est pas hors sujet:
    voici quasiment le meme programme en C (peut-etre que ça marche en ocaml) qui désalloue correctement les variables d_init quand y'en a plus besoin:

    {
    {variables_globales_d_init qui font 50 Mo ;
    static variables_pour_la_suite qui font 50 Mo ;
    mon code d'init qui utilise les variables d'init ;
    }
    mon code pour la suite qui utilise plus les variables d'init ;
    }

    -------------------------------
    voici encore une autre version, car
    le plus sûr et le plus simple est bien sûr de le réordonner un peu:
    -------------------------------------

    {variables_pour_la_suite qui font 50 Mo ;

    {variables_globales_d_init qui font 50 Mo ;
    mon code d'init qui utilise les variables d'init ;
    }
    mon code pour la suite qui utilise plus les variables d'init ;
    }

    /* un autre avantage de cette manière de programmer avec des blocs supplémentaires, c'est que ça oblige ensuite le programmeur à éviter l'utilisation de variables globales qui génèrent des erreurs quand elles sont utilisées en même temps à des endroits très différents d'un programme */

    • [^] # Re: L'allocation mémoire et les langages fonctionnels

      Posté par  . Évalué à 1.

      Le monsieur, il veut un programme de porc (sic).

      "Il faut" (Ezekiel 18:4) "forniquer" (Corinthiens 6:9, 10) "avec des chiens" (Thessaloniciens 1:6-9) "morts" (Timothée 3:1-10).

      • [^] # Re: L'allocation mémoire et les langages fonctionnels

        Posté par  . Évalué à 1.

        Le monsieur, il veut un programme de porc (sic).

        Le monsieur devrait trouver, il en existe beaucoup, et beaucoup de gens savent en produire :)

        Le monsieur, en fait, se casse le nez contre le celebre probleme dit "garbage in, garbage out", ou en bon francais avec de la merde on ne produit que de la merde. Il est raisonnablement simple d'ecrire un programme qui ne gache pas la memoire de cette facon si on utilise un langage raisonnablement bien fichu, ce qui est le cas d'ocaml. Mais on ne sait pas encore faire des langages qui permettent a de mauvais programmeurs d'ecrire des bons programmes. Tant mieux d'ailleurs, parce que ce jour la (en supposant qu'il arrive un jour...), on n'aura plus besoin de bons programmeurs !

        Pour le cas particulier de la liveness analisys dans Ocaml, il est probable qu'il puisse demeler les cas les plus simples, je ne sais pas dans quelle mesure celui-la en fait partie (ca doit dependre en grande partie du code d'init des blocs de 50Mo). Mais un programmeur suffisamment mauvais arrivera toujours a ecrire des horreurs trop horribles pour que le compilo puisse les rattrapper.

  • # Re: L'allocation mémoire et les langages fonctionnels

    Posté par  . Évalué à 1.

    le module Weak d'ocaml devrait te permettre de faire ce que tu veux: l'expression n'est pas liberee explicitement, mais on indique au GC qu'il peut la liberer a tout instant.
    http://www.pps.jussieu.fr/Livres/ora/DA-OCAML/book-ora090.html(...)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.