RFR (M): 8003853: specify offset of IC load in java_to_interp stub

[Christian Thalinger]

Thank you.  -- Chris

On Apr 30, 2013, at 8:10 AM, Dean Long <dean.long at oracle.com> wrote:

> It's in hotspot-emb now.
> 
> dl
> 
> On 4/30/2013 1:10 AM, Lindenmaier, Goetz wrote:
>> Hi,
>>  
>> Does the change pass your tests?
>> When will it appear in a repo? I assume it will go to hotspot-comp, right?
>> Or do I have to look somewhere else.
>>  
>> Best regards,
>>   Goetz.
>>  
>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
>> Sent: Mittwoch, 24. April 2013 21:17
>> To: Lindenmaier, Goetz
>> Cc: hotspot-compiler-dev at openjdk.java.net
>> Subject: Re: RFR (M): 8003853: specify offset of IC load in java_to_interp stub
>>  
>> Looks good.  Dean, can you push the change?
>>  
>> -- Chris
>>  
>> On Apr 24, 2013, at 1:47 AM, "Lindenmaier, Goetz" <goetz.lindenmaier at sap.com> wrote:
>> 
>> 
>> Hi,
>>  
>> Yes, your comments make the code look better.
>> I made a new webrev:
>> http://cr.openjdk.java.net/~goetz/webrevs/8003853-4/
>>  
>> I did not do a zero build.
>>  
>> Best regards,
>>   Goetz.
>>  
>>  
>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
>> Sent: Dienstag, 23. April 2013 21:06
>> To: Lindenmaier, Goetz
>> Cc: hotspot-compiler-dev at openjdk.java.net
>> Subject: Re: RFR (M): 8003853: specify offset of IC load in java_to_interp stub
>>  
>>  
>> On Apr 23, 2013, at 11:00 AM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>> 
>> 
>> 
>> The change looks good.  I have some minor comments though:
>> src/share/vm/code/compiledIC.hpp:
>> 
>> +  static uint to_interp_stub_size();
>> +  static uint reloc_to_interp_stub();
>> +            stub_size  += CompiledStaticCall::to_interp_stub_size();
>> +            reloc_size += CompiledStaticCall::reloc_to_interp_stub();
>> stub_size and reloc_size are ints.  We should change the return type from uint to int.
>>  
>> src/cpu/x86/vm/compiledIC_x86.cpp:
>>  108 uint CompiledStaticCall::to_interp_stub_size() {
>>  109   return 10              // movl; jmp
>>  110          LP64_ONLY(+5);  // movq (1+1+8); jmp (1+4)
>>  111 }
>> In expectancy of future changes we should do:
>>  108 uint CompiledStaticCall::to_interp_stub_size() {
>>  109   return NOT_LP64(10)    // movl; jmp
>>  110          LP64_ONLY(15);  // movq (1+1+8); jmp (1+4)
>>  111 }
>> And one question unrelated to this change (because it was there before):
>>  
>> src/cpu/sparc/vm/compiledIC_sparc.cpp:
>>  126 // Relocation entries for call stub, compiled java to interpreter.
>>  127 uint CompiledStaticCall::reloc_to_interp_stub() {
>>  128   return 10;  // 4 in emit_java_to_interp + 1 in Java_Static_Call
>>  129 }
>> Why does it say 5 relocations but returns 10?
>>  
>> Did someone try a Zero build?
>>  
>> Presumably not because Zero builds are broken right now.  I just filed:
>>  
>> 8013067: Zero builds are broken after 8010862
>>  
>> -- Chris
>>  
>>  
>> -- Chris
>>  
>> On Apr 23, 2013, at 1:09 AM, "Lindenmaier, Goetz" <goetz.lindenmaier at sap.com> wrote:
>> 
>> 
>> 
>> Hi all,
>>  
>> In the java_to_interp stub of CompiledStaticCalls one relocation is used to find
>> two code locations:
>> -          the beginning of the stub
>> -          the IC load instruction.
>> On x86 and sparc, the IC load instruction is the first instruction of the stub,
>> thus both locations have the same address.
>> On PPC, the IC load instruction is not the first instruction in the stub, thus
>> we must add an offset to the relocation to access it.
>>  
>> As the manipulation of  CompiledStaticCalls is in shared code, we would have
>> to introduce platform dependencies there.
>>  
>> This change moves the platform dependent code from CompiledStaticCall
>> to a new file compiledIC_<cpu>.cpp.  It also moves the code issuing the
>> stub from the ad file to this new file into the class CompiledStaticCall.
>> This removes redundancies between x86_64.ad and x86_32.ad.  Also,
>> ‘extern’ declarations in compile.cpp can be replaced by properly typed
>> Calls to methods in CompiledStaticCall.
>>  
>> Dean Long ran this change through JPRT with status OK (thanks!).
>>  
>> Please review and push this change.
>> http://cr.openjdk.java.net/~goetz/webrevs/8003853-3/
>>  
>> Best regards,
>>   Goetz Lindenmaier
>>  
>>  
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130430/3abd051f/attachment-0001.html