RFR (M): 7200949: JSR 292: rubybench/bench/time/bench_base64.rb fails with jruby.jar not on boot class path (original) (raw)

Christian Thalinger christian.thalinger at oracle.com
Fri Sep 28 14:36:21 PDT 2012

On Sep 27, 2012, at 5:24 PM, John Rose <john.r.rose at oracle.com> wrote:

On Sep 27, 2012, at 4:34 PM, Christian Thalinger wrote:

http://cr.openjdk.java.net/~twisti/7200949

7200949: JSR 292: rubybench/bench/time/benchbase64.rb fails with jruby.jar not on boot class path Reviewed-by: It looks good. (Having all the references to the jli.MethodType objects makes me wonder if we should have a JVM-internal analog MethodType, to represent resolved signatures. I suppose what we have is reasonably economical.) I'm not fully comfortable with the handshake between Rewriter and CPCache (last diff hunk in cpCache.cpp). Ideally, if you were to redefine indyappendixoffset=1 and indymethodtypeoffset=0 it would either Just Work (tm) or throw an assert. It's not clear that this is the case here.

The problem is the interpreter: it uses f1 to read the appendix. So the appendix has to be at offset 0 and other data after that.

I can either:

a) add the offset to the index in the interpreter (then it's fool-proof) or b) add an assert to TemplateTable::prepare_invoke:

I did the latter, made rewriter and cpCache change more generic and updated the webrev.

-- Chris

Maybe this code would help in rewriter.cpp: int refindex = appendixindex - indyappendixoffset; assert(refindex == methodtypeindex - indymethodtypeoffset, "consistent offsets"); ... use refindex in sequel ... And something similar in cpCache.cpp, using a neutral refindex value. — John

More information about the hotspot-compiler-dev mailing list