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