Request for reviews (L): 6939207: refactor constant pool index processing

[John Rose]

I have completed this change by centralizing the byte-swapping logic for bytecode instruction operands.

Here is the updated webrev:
  http://cr.openjdk.java.net/~jrose/6939207/webrev.00

The result has three advantages:  (a) It is more regular, (b) it has less duplicated code, and (c) it is a more robust basis for adding new bytecode operands (i.e., constant pool types).

-- John

On Mar 30, 2010, at 4:18 AM, John Rose wrote:

> 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