Request for reviews (L): 6939207: refactor constant pool index processing
John Rose
john.r.rose at oracle.com
Tue Mar 30 04:18:28 PDT 2010
6939207: refactor constant pool index processing
Summary: Factored cleanup which prepares for enhanced ldc semantics.
http://cr.openjdk.java.net/~jrose/6939207/webrev.00
Bug 6939203 (JSR 292 needs method handle constants) requires an extension to the construct pool structure and the ldc bytecode. In particular, it needs to use the CP cache to manage method references, and therefore the ldc bytecode (when used by the new functionality) need to refer to a CP cache index.
To do this safely, the JVM's bytecode parsing modules must make a more rigorous distinction between types of bytecode indexes. This change makes clear the difference between (a) a CP index and (b) a CP cache index, and also (1) a network-byte-order index and (2) a native-byte-order index. With clarified distinctions, enforced mechanically, we can safely make the needed modifications.
This change may be incomplete. I'd like advice on whether to push the change farther. Specifically, we should push all byte swapping to the point where data
is loaded, because the byte order is known most accurately at that point. Currently, we swap it in the CP accessors. See the temporary function 'get_index_native_swap' and the FIXME comments nearby.
-- John
More information about the hotspot-compiler-dev
mailing list