Request for reviews (S): 6827505: sizing logic for vtable and itable stubs needs self-check

Vladimir Kozlov Vladimir.Kozlov at Sun.COM
Tue Apr 7 18:59:09 PDT 2009


It is not vtable index but offset:

sparc:
   66   int entry_offset = instanceKlass::vtable_start_offset() + vtable_index*vtableEntry::size();
   80   int v_off = entry_offset*wordSize + vtableEntry::method_offset_in_bytes();
   81   if( __ is_simm13(v_off) ) {
   82     __ ld_ptr(G3, v_off, G5_method);
   83   } else {
   84     __ set(v_off,G5);
   85     __ ld_ptr(G3, G5, G5_method);
   86   }

x64:
   79   // load methodOop and target address
   80   const Register method = rbx;
   81
   82   __ movptr(method, Address(rax,
   83                             entry_offset * wordSize +
   84                             vtableEntry::method_offset_in_bytes()));


but you are right, most likely we never see offset > 32 bits.

Thanks,
Vladimir

John Rose wrote:
> On Apr 7, 2009, at 4:42 PM, Vladimir Kozlov wrote:
> 
>> John Rose wrote:
>>> Here are some simple asserts and comments which should make it easier 
>>> to maintain the correct sizing of certain stubs:
>>>  http://cr.openjdk.java.net/~jrose/6827505/webrev.00/
>>
>> Why the assert checks the room only for first 9 entries?:
>> "table_index > 10 ||"
> 
> For the first 9 entries it checks a more stringent limit.  That is, it 
> requires that the size estimate has 3 or 8 bytes of slop, under the 
> assumption that eventually (after index is much larger than 10) the stub 
> will grow slightly because the addressing modes will expand beyond their 
> minimum size.
> 
> The number 10 could be as large as 255 (or 2047 on sparc).  Any small 
> number will do, since the assertion doesn't do interesting work after it 
> checks index=0 and maybe index=1, depending on what the tiny addressing 
> modes look like.
> 
>> Why you did not add +5 for sparc LP64 for slop?:
>>
>> int slop = (2 LP64_ONLY(+5))*BytesPerInstWord;
> 
> Because we will never have vtable indexes larger than about 20 bits 
> wide.  The stubs do not contain materialized constants, so there are 
> never 64-bit values in them.
> 
>> For x64 (64-bit x86) the address could be unreachable,
>> so the slop should be large:
>>
>> void MacroAssembler::jump(AddressLiteral dst) {
>>  if (reachable(dst)) {
>>    jmp_literal(dst.target(), dst.rspec());
>>  } else {
>>    lea(rscratch1, dst);
>>    jmp(rscratch1);
>>  }
>> }
> 
> Yes, but the stubs inherently jump through a register, not to a fixed 
> external address.
> 
> I can add these points as comments, if you want.  What do you think?
> 
> -- John



More information about the hotspot-compiler-dev mailing list