[MVT] Issues with VDEFAULT + VWITHFIELD
forax at univ-mlv.fr
forax at univ-mlv.fr
Thu Aug 24 20:56:43 UTC 2017
----- Mail original -----
> De: "Frederic Parain" <frederic.parain at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "valhalla-dev" <valhalla-dev at openjdk.java.net>
> Envoyé: Jeudi 24 Août 2017 22:48:25
> Objet: Re: [MVT] Issues with VDEFAULT + VWITHFIELD
...
>>
>> 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
>
i see, i've forgotten that,
so i will have to update the ASM verifier sooner than i thought :)
thanks,
Rémi
More information about the valhalla-dev
mailing list