for example like HotSpot.. I stopped its complied mode and I was thinking bytecode of classes should be in the memory by the opcode presents..
But it seems I am wrong..
You can get some hints by looking at the documentation of an API that forces the JVM to transform the internal representation back into the official class file format:
http://docs.oracle.com/javase/7/docs/api/java/lang/instrument/Instrumentation.html#retransformClasses(java.lang.Class...)
The initial class file bytes represent the bytes passed to ClassLoader.defineClass or redefineClasses (before any transformations were applied), however they might not exactly match them. The constant pool might not have the same layout or contents. The constant pool may have more or fewer entries. Constant pool entries may be in a different order; however, constant pool indices in the bytecodes of methods will correspond. Some attributes may not be present. Where order is not meaningful, for example the order of methods, order might not be preserved
From this documentation you can draw the conclusion that you can expect instructions accessing the constant pool to look different, at least they may have different indices, and that you cannot assume that methods are placed into a contiguous memory space. This does not imply that these are the only transformations, but all others can be reversed if needed— at least in a JVM that supports Instrumentation.
While running the code the JVM might replace instructions by specialized VM-internal instructions to optimize further execution. If you are curious what kind of instruction a JVM might have you can run Oracle’s HotSpot-Engine with the arguments
-XX:+UnlockDiagnosticVMOptions
-XX:+PrintInterpreter
Then it will print the table of all instructions and their associated native code as used by the interpreter. This table will necessarily contain these specialized instructions. E.g. on my machine and jdk 1.7 I see about 30 non-standard bytecode instructions in the range 203 to 231.