Request for reviews (L): 6939203: JSR 292 needs method handle constants
tom.rodriguez at oracle.com
Tue Jun 8 21:12:53 PDT 2010
On Jun 8, 2010, at 7:08 PM, John Rose wrote:
> 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.
I thought it always read in native order. If that weren't the case then nothing would work, right?
>>> 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.
> -- John
More information about the hotspot-compiler-dev