In Valhalla, it appears that the bytecodes of primitive classes are garbled before being retransformed by sun.instrument.InstrumentationImpl.

See the test RedefinePrimitive which is modeled after the RedefineRecord test. Explanation is as follow:

0) The test will first run RedefinePrimitive to create an redefineagent.jar
1) The test will then run RedefinePrimitive again, starting itself inside a new process, using this redefineagent.jar file an an -javaagent.
2) This will launch RedefinePrimitive.premain which will set up a transformer (LoggingTransformer) and add it to the Instrumentation.
3) Then RedefinePrimitive$PrimitiveTester is explicitly loaded, triggering the LoggingTransformer before loading. The class is loaded as expected, which I've verified in classFileParser.cpp.
4) Then the loaded class is passed to Instrumentation.retransformClasses(...), and passed yet through the LoggingTransformer. This time, the bytecode is garbled slightly (see below).
5) When these bytes are checked by classFileParser.cpp, the problems are found in ClassFileParser::parse_methods, explicitly when checking the constructor, yielding a ClassFormatError: "Method <init> in class RedefinePrimitive$PrimitiveTester (not an inline class) has illegal modifiers: 0x8"

I've attached the difference in 'javap' outputs of RedefinePrimitive$PrimitiveTester (original is 'load.txt', the one seen when redefining is 'redefine.txt'):
 - the 0x10 access flag for the class is missing (which is why ClassFileParser claims it's not an inline class)
 - The field indexes of the three "withfield" instructions are modified to something wrong.
Other changes, seen when testing a primitive record:
- The order of the methods were changed
- The parameter names attribute in the constructor were stripped.

I've debugged so far as the JvmtiClassFileReconstituter, this could be it.