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

[Vladimir Kozlov]

Looks good.

Vladimir

Christian Thalinger wrote:
> 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
>