bug 6693236 fix
keith.mcguigan at oracle.com
Thu Jul 8 06:52:05 PDT 2010
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.
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.
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
allows the existing tools to still work for version 50 class
the tools need to migrate to the new format eventually because the
behavior may not be feasible to support in the future. Besides,
take advantage of the improved verifier until your class files
pass the type
checking verifier. This is especially important if your
More information about the hotspot-runtime-dev