Request for reviews (L): 6939203: JSR 292 needs method handle constants

[John Rose]

On Jun 8, 2010, at 5:56 PM, Tom Rodriguez wrote:

>> The SA code is more complete, although it's not clear to what "really complete" looks like.  It looks like SA bytecode walkers don't deal with the results of the JVM's Rewriter.
> 
> What do you mean?

It looks like it only reads indexes (e.g., of getfield) in big-endian order; CP cache indexes are in native order.  Also, the code which uses the CP cache indexes does not seem to exist in places like GenerateOopMap.

>> How can I test the ClassWriter?
> 
> jcoreproc.sh will dump all the classfiles from a JVM, or you can use the dumpclass command in clhsdbproc.sh.  So dump something that has one of your new classes loaded and compare the result against the original.  It should be the same, apart from some missing sections like the annotations which  I think get dropped along the way.  You can use the jdec utility to dump a fairly raw dump of the class files to make sure they look exactly the same.
> 
> java -classpath /java/re/jct-tools/3.0.3/archive/fcs/binaries/asmtools.jar javasoft.sqe.jdec.Main foo.class
> 
> It's a printed form the class file format itself so it shows the true structure which should be exactly the same as the original.
> 
> You can test the bytecode disassembler too by printing a methodOop in hsdb.  Using class to get klassOop, using print on that to get the methods with their methodOops and then print the methodOop.

I'll try that and make adjustments if needed.

> I think it all looks good.

Thanks!

-- John