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

[Christian Thalinger]

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/bench_base64.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 _indy_appendix_offset=1 and _indy_method_type_offset=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:

+     assert(ConstantPoolCacheEntry::_indy_resolved_references_appendix_offset == 0, "index points to 0");

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 ref_index = appendix_index - _indy_appendix_offset;
>  assert(ref_index == method_type_index - _indy_method_type_offset, "consistent offsets");
>  ... use ref_index in sequel ...
> 
> And something similar in cpCache.cpp, using a neutral ref_index value.
> 
> — John