Que devrait sacrifier le JVM pour mettre en œuvre l'optimisation de l'appel final?

Question

Les gens disent que la mise en œuvre de clojure est excellente, mis à part la limitation de l’absence d’optimisation de l’appel de la queue - une limitation de la mise en œuvre non pas de la mise en oeuvre de la clojure.

http://lambda-the-ultimate.org/node/2547

Il a été dit qu'implémenter TCO en Python serait un sacrifice

• vidages de trace de pile et
• régularité de débogage.

Expliquez-moi quel est le problème avec l'optimisation des appels de queue et pourquoi Python en a besoin

Faudrait-il faire les mêmes sacrifices pour une mise en œuvre jvm du TCO? Faut-il sacrifier autre chose?

Answer 1

Bien que différent (en ce sens que les instructions il existaient déjà), il convient de noter l'effort supplémentaire que le .Net L’équipe JIT 64 bits a dû passer pour respecter tous les appels en aval.

J'appelle en particulier le commentaire:

  

Évidemment, si vous devez déboguer ou profiler votre code optimisé, soyez prêt à gérer les piles d'appels qui donnent l'impression qu'il ne manque que quelques images.

Je pense qu'il est très peu probable que la machine virtuelle Java puisse éviter cela non plus.

Étant donné que, dans les cas où une optimisation d'appel final a été demandée, le JIT devrait supposer qu'il est requis pour éviter un débordement de pile, ce n'est pas quelque chose qui peut simplement être désactivé dans les versions Debug. Ils ne servent pas beaucoup au débogage s’ils se bloquent avant que vous ne passiez à la partie intéressante. L’optimisation est en fait une fonctionnalité permanente et un problème pour les traces de pile affectées par celle-ci.

Il convient de souligner que toute optimisation qui évite de créer un cadre de pile réel lorsqu’une opération que le programmeur décrit / comprend de manière conceptuelle comme étant une opération de pile (appelant une fonction par exemple) provoquera de manière inhérente une déconnexion entre ce qui est présenté. à l'utilisateur lors du débogage / fourniture de la trace de pile et de la réalité.
Ceci est inévitable car le code décrivant l'opération devient de plus en plus séparé de la mécanique de la machine à états effectuant l'opération.

Answer 2

Le travail est en cours pour ajouter des appels en fin de processus à la machine virtuelle Java. Il existe une page de wiki sur certains détails.

Answer 3

Oui, en règle générale, la mise en œuvre du TCO vous empêchera d'obtenir des traces de pile complètes. Cela est inévitable, car l’intérêt principal du coût total de possession est d’éviter la création de cadres de pile supplémentaires.

Il est également intéressant de noter que Clojure a une option "récurrente" non consommatrice de pile. fonctionnalité permettant de contourner cette contrainte sur les versions actuelles de la machine virtuelle Java.

Exemple:

(defn triangle [n accumulator] 
  (if 
    (<= n 0)  
      accumulator
      (recur (dec n) (+ n accumulator))))

(triangle 1000000 0)

=> 500000500000     (note stack does not explode here!)