bug 6693236 fix

David Holmes David.Holmes at oracle.com
Thu Jul 8 03:13:44 PDT 2010


Rémi Forax said the following on 07/08/10 19:55:
> Hi David,
> I've no problem with the fact that the default configuration of jdk7
> mandate to use of the split verifier.
> But the patch for bug 6693236 also make FailOverOldVerifier command line 
> flag useless.
> 
> I think it's an error. FailOverOldVerifier should "fail over the old 
> verifier" and not be silently ignored.

For Java 7 you're not permitted to failover to the old verifier so the 
choices are to:

a) silently ignore it
b) ignore it but issue a warning
c) refuse to start the VM

I presume you would prefer (b) or (c)?

David

> 
> Rémi
> 
> 
> Le 08/07/2010 05:55, David Holmes a écrit :
>> Hi Remi,
>>
>> As noone has commented on this let me :)
>>
>> As the bug report describes:
>>
>> According to 4.11.1 paragraph of JVMS3
>> "A class file whose version number is greater than to 50.0
>> must be verified using the typechecker rules"
>>
>> So strictly speaking 1.6 was not compliant with the spec for practical 
>> reasons, but this non-compliance has been removed for Java 7.
>>
>> David Holmes
>>
>> Rémi Forax said the following on 06/27/10 23:45:
>>> Hello all,
>>> 1.7bb99 contains a patch for bug 6693236.
>>> http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/e40a3601bc1f
>>>
>>> This change has a big impact for all projects that does bytecode 
>>> instrumentation
>>> because it requires to generate stackmap information for classfile 51.0.
>>>
>>> During 1.6 time frame, the command line flag FailOverToOldVerifier 
>>> was added
>>> to ease the transition. (see https://jdk.dev.java.net/verifier.html  )
>>> Later it was decided to enable that flag by default for 1.6.
>>>
>>> The patch deactivates type inference for classfile 51.0,
>>> I have no problem with that,
>>> but it also deactivates FailOverToOldVerifier flag for classfile 51.0.
>>>
>>> I want to know if there a reason to deactivate the command line flag
>>> or if it's just a side-effect of the fix.
>>>
>>> Rémi
>>>
>>>
>>>
>>>
> 


More information about the hotspot-runtime-dev mailing list