[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