bug 6693236 fix

[Kelly O'Hair]

On Jul 8, 2010, at 6:52 AM, Keith McGuigan wrote:

> Rémi Forax wrote:
>> Hi Keith,
>> The problem is that bytecode transformations at runtime is a common  
>> trick,
>> especially since the VM has an agent API (java.lanf.instrumentation).
>> Such agents modify the bytecode at runtime by rewritting it.
>> During the rewrite, the stackmap information are often discarded,
>> because the agent was written before the release of 1.6 or
>> because generating stackmap frames takes more time than using
>> the old verifier.
>> With this fix, these agent libraries will stop working with 1.7  
>> classfiles
>> and there is no workaround until the agent code is updated.
>
> Hi Rémi,
>
> I understand the issues.  The failover flag has been in place for  
> years as a stopgap measure to let tools "catch up" to the new  
> classfile format.  The specification is quite clear that stackmaps  
> are needed, so discarding them for convenience reasons isn't really  
> an option (as far as the spec/JVM is concerned).  In order to  
> process classfiles with version >= 51, the tools must be updated to  
> emit the correct stackmaps.  Otherwise they're not generating valid  
> classfiles.  Tools that can't generate stackmaps for whatever  
> reasons shouldn't modify classfiles with version 51, then, I would  
> think.

I vaguely recall that they could also downgrade the classfile version  
too, i.e. transform the classfile to an older version.
Seemed like there were a variety of ways to deal with it, but many  
required actually making changes to the classfile
re-writer code.

Bytecode transformation code that did not inspect and correctly deal  
with the classfile version specifics may have been
a common mistake. They cannot ignore the classfile version.

-kto

>
> There is a workaround, though, if one does not care that modified  
> classes are verifiable, and that is to disable verification with - 
> Xverify:none.  You can use that instead of the failover option but  
> keep in mind that you're treading on dangerous territory.
>
> From https://jdk.dev.java.net/verifier.html:
>
>     If you develop or use tools that manipulate Java byte code, such  
> as
>     profilers, loggers, and class file rewriters, your tools may not  
> work
>     correctly with the new StackMapTable attribute. The fall-back  
> behavior
>     allows the existing tools to still work for version 50 class  
> files. However,
>     the tools need to migrate to the new format eventually because  
> the fall-back
>     behavior may not be feasible to support in the future. Besides,  
> you cannot
>     take advantage of the improved verifier until your class files  
> pass the type
>     checking verifier. This is especially important if your  
> applications are
>     performance sensitive.
>
>
> --
> - Keith
>
> --
> - Keith
>