bug 6693236 fix

[Keith McGuigan]

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.

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