Est-ce un bug dans Scala 2.9.1 mise en œuvre paresseuse ou juste un artefact de décompilation

Question

J'envisage d'utiliser Scala sur un joli programme de calcul intensif. Le profilage de la version C++ de notre code révèle que nous pourrions bénéficier de manière significative de l'évaluation paresseuse. Je l'ai essayé dans Scala 2.9.1 et l'aime vraiment. Cependant, quand j'ai couru la classe à travers un décompilateur, la mise en œuvre ne semblait pas très bien. Je suppose que c'est un artefact de la décompilateur, mais je voulais obtenir une réponse plus concluante ...

considérer l'exemple trivial suivant:

class TrivialAngle(radians : Double) 
{ 
    lazy val sin = math.sin(radians) 
} 

quand je décompiler, je reçois ceci:

import scala.ScalaObject; 
import scala.math.package.; 
import scala.reflect.ScalaSignature; 

@ScalaSignature(bytes="omitted") 
public class TrivialAngle 
    implements ScalaObject 
{ 
    private final double radians; 
    private double sin; 
    public volatile int bitmap$0; 

    public double sin() 
    { 
    if ((this.bitmap$0 & 0x1) == 0); 
    synchronized (this) 
    { 
     if (
     (this.bitmap$0 & 0x1) == 0) 
     { 
     this.sin = package..MODULE$.sin(this.radians); 
     this.bitmap$0 |= 1; 
     } 
     return this.sin; 
    } 
    } 

    public TrivialAngle(double radians) 
    { 
    } 
} 

Pour moi, le bloc de retour est au mauvais endroit, et vous obtiendrez toujours le verrou. Cela ne peut pas être ce que fait le vrai code, mais je suis incapable de le confirmer. Est-ce que quelqu'un peut confirmer ou nier que j'ai une fausse décompilation, et que l'implémentation paresseuse est quelque peu raisonnable (ie, verrouille uniquement quand elle calcule la valeur, et n'acquiert pas le verrou pour les appels suivants?)

Merci!

Pour référence, c'est le décompilateur je: http://java.decompiler.free.fr/?q=jdgui

Answer 1

scala -Xprint:jvm révèle l'histoire vraie:

[[syntax trees at end of jvm]]// Scala source: lazy.scala 
package <empty> { 
    class TrivialAngle extends java.lang.Object with ScalaObject { 
    @volatile protected var bitmap$0: Int = 0; 
    <paramaccessor> private[this] val radians: Double = _; 
    lazy private[this] var sin: Double = _; 
    <stable> <accessor> lazy def sin(): Double = { 
     if (TrivialAngle.this.bitmap$0.&(1).==(0)) 
     { 
      TrivialAngle.this.synchronized({ 
      if (TrivialAngle.this.bitmap$0.&(1).==(0)) 
       { 
       TrivialAngle.this.sin = scala.math.`package`.sin(TrivialAngle.this.radians); 
       TrivialAngle.this.bitmap$0 = TrivialAngle.this.bitmap$0.|(1); 
       () 
       }; 
      scala.runtime.BoxedUnit.UNIT 
      }); 
     () 
     }; 
     TrivialAngle.this.sin 
    }; 
    def this(radians: Double): TrivialAngle = { 
     TrivialAngle.this.radians = radians; 
     TrivialAngle.super.this(); 
    () 
    } 
    } 
} 

Il est un (depuis JVM 1.5) en toute sécurité, et très rapide, serrure revérifié.

Plus de détails:

What's the (hidden) cost of Scala's lazy val?

Sachez que si vous avez plusieurs membres de val paresseux dans une classe, une seule d'entre elles peut être initialisé à la fois, car ils sont gardés par synchronized(this) { ... }.

Answer 2

Ce que je reçois avec javap -c ne correspond pas à votre décompiler. En particulier, il n'y a pas d'entrée de moniteur lorsque le champ est initialisé. Version 2.9.1 aussi. Il y a toujours la barrière de la mémoire impliquée par l'accès volatile bien sûr, de sorte qu'il ne soit pas complètement libre. Commentaires commençant par /// sont les miens

public double sin(); 
    Code: 
    0: aload_0 
    1: getfield  #14; //Field bitmap$0:I 
    4: iconst_1 
    5: iand 
    6: iconst_0 
    7: if_icmpne  54 /// if getField & 1 == O goto 54, skip lock 
    10: aload_0 
    11: dup 
    12: astore_1 
    13: monitorenter 
      /// 14 to 52 reasonably equivalent to synchronized block 
      /// in your decompiled code, without the return 
    53: monitorexit 
    54: aload_0 
    55: getfield  #27; //Field sin:D 
    58: dreturn  /// return outside lock 
    59: aload_1  /// (this would be the finally implied by the lock) 
    60: monitorexit 
    61: athrow 
    Exception table: 
    from to target type 
    14 54 59 any