Local variables not always resolved when dynamically loaded scripts cause recompile of target class

The new capability for loading dynamic scripts has exposed a flaw in the implementation of the Sun and OpenJDK JVMs which causes problems when loading scripts which reference local variables (also method parameters by name). This is true even if the class was compiled with local variable info included. The problem only manifests is a specific case i.e.

• the uploaded script refers to local variables in a target method whose class has already been loaded
• the class was not subject to a (successful) bytecode transformation prior to the upload

So, for example, when uploading rules which redefine existing, successfully applied rules this problem will not manifest. Nor will it manifest if rules are dynamically loaded before the application has got round to executing code in the target class (modulo the vagaries of JVM pre-loading/resolution). The most common case where it will manifest is when uploading rules which correct errors in a script provided at boot time. If the errors stopped the class from being transformed when originally loaded and a transformation was not applied then references to local vars will no longer be resolved when dynamically uploading the corrected rules. Unfortunately, the latter is one of the common use cases promoting the inclusion of the dynamic load capability.

The cause of this problem is a bug in the JVM (this applies to JDK 6 java 14.0-b16 and JDK 7 16.0-b06). The bug relates to a problem with caching of loaded bytecode. Normally the original byecode of transformed classes is retained so that retransformation requests can be applied to the same bytecodes. However, the bytecode of untransformed classes is not retained in order to save space. If an agent makes a retransform request for a class which was not previously subject to transformation the JVM needs somehow to obtain a bytecode array in order to supply it to all registered transformers. So, in this case it reconstitutes the bytecode from the JVM-internal representation of the class. Unfortunately, the latest JDK 6/7 reconstitute code does not regenerate the local variable tables for the bytecode.

An OpenJDK bugzilla (#100100) has been raised for this bug and a patch provided. The patch has not yet been integrated into a release.