bug 6693236 fix
kelly.ohair at oracle.com
Thu Jul 8 09:20:08 PDT 2010
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
>> 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
>> 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
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
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.
> 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
> profilers, loggers, and class file rewriters, your tools may not
> correctly with the new StackMapTable attribute. The fall-back
> 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
More information about the hotspot-runtime-dev