[MVT] Issues with VDEFAULT + VWITHFIELD

[Frederic Parain]

> On Aug 24, 2017, at 16:18, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> With the following base code
> 
> @jvm/internal/value/ValueCapableClass
> public final class Test {
>  private final int value;
> 
>  public java.lang.String toString();
>    Code:
>       0: aload_0
>       1: getfield      #11                 // Field value:I
>       4: invokedynamic #23,  0             // InvokeDynamic #0:makeConcatWithConstants:(I)Ljava/lang/String;
>       9: areturn
> 
>  public static void main(java.lang.String[]);
>    Code:
>       0: vdefault      #27                 // class ";QTest;"
>       3: iconst_3
>       4: vwithfield    #28                 // Field ";QTest;".value:I
>       7: vstore        1
>       9: getstatic     #34                 // Field java/lang/System.out:Ljava/io/PrintStream;
>      12: vload         1
>      14: vbox          #2                  // class Test
>      17: invokevirtual #40                 // Method java/io/PrintStream.println:(Ljava/lang/Object;)V
>      20: return
> }
> 
> 
> for all the test, mvt/Test is the value capable class and ;Qmvt/Test$Value; is the corresponding value type.
> 
> 1. using VDEFAULT with the clas ref and not the value type ref is allowed (at least with the product VM)
>   VDEFAULT "mvt/Test" 
> 
> 2. worst, you can then call VWITHFIELD, it works again !
>   VDEFAULT "mvt/Test"
>   ICONST_3
>   VWITHFIELD, "mvt/Test", "value", "I”)

Regarding issues 1 and 2: these are incorrect bytecode sequences that will eventually be
detected and rejected by the verifier. The code in the JVM executing the bytecodes assumes that
class files have been verified and by consequence, do not check issues that should have been
catched by the verifier, because it would be a waste of time.

One big problem today, is that the verifier is not ready yet, so incorrect bytecode sequences
are not detected, and the JVM tries to execute them anyway with strange and unpredictable behaviors.

But we used to put a lot of assert() statements in our code, so if you run your code with a debug
VM, these assert() could catch more issues, but not with the same reliability as the verifier does.

Several of us, in this project, had unpleasant experiences with incorrect bytecode sequences, but
there’s not that much we can do before the verifier is ready.

Regards,

Fred


> 3. if the field 'value' is private (final),
>   the following code raises an IllegalAccessError
>   VDEFAULT ;Qmvt/Test$Value;
>   ICONST_3
>   VWITHFIELD, ;Qmvt/Test$Value; value I
> 
>   Exception in thread "main" java.lang.IllegalAccessError: tried to access field mvt.Test$Value.value from class mvt.Test
> 
>   Does the MVT support nestmates ??   
> 
> 4. same code as above, but with the field 'value' declared package private or public.
>   Note that mvt/Test and ;Qmvt/Test$Value; should be in the same package.
> 
>   Exception in thread "main" java.lang.IllegalAccessError: Update to non-static final field mvt.Test$Value.value attempted from a different class (mvt.Test) than the field's declaring class
> 	at mvt.Test.main(Unknown Source)
> 
>   so i do not know how i can use VWITHFIELD ?
> 
> cheers,
> Rémi
>