RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]

Christian Thalinger christian.thalinger at oracle.com
Mon Nov 26 16:53:19 PST 2012


On Nov 22, 2012, at 8:51 AM, "Lindenmaier, Goetz" <goetz.lindenmaier at sap.com> wrote:

> Hi Chris,
> 
> We put it into the ad file because it describes an offset into the stub that is
> generated from the ad file by emit_java_to_interp(CodeBuffer& cbuf), 
> used by ir  node CallStaticJavaDirect.  Maybe I should not call it stub, but it's 
> generated into the stubs section of the code buffer.
> If that stub generator is moved out of the ad file to shared compiler code, one should
> move the field with it, but for the current implementation I think that's fine.
> 
> Does C1 generate the same stub? Or is the CompiledStaticCall a C2 feature?
> If so, one could protect the whole thing by #ifdef COMPILER2.

Why do you need all these shared code changes when you have this in emit_java_to_interp_stub?

  // Create a static stub relocation which relates this stub
  // with the call instruction at insts_call_instruction_offset in the
  // instructions code-section.
  __ relocate(static_stub_Relocation::spec(__ code()->insts()->start() + insts_relocation_offset));

Do you need two relocations?  I'm confused.

-- Chris

> 
> Thanks for all the bugids!
> 
> Best regards,
>  Goetz.
> 
> -----Original Message-----
> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
> Sent: Mittwoch, 21. November 2012 19:53
> To: Lindenmaier, Goetz
> Cc: hotspot-compiler-dev at openjdk.java.net
> Subject: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
> 
> 
> On Nov 21, 2012, at 12:15 AM, "Lindenmaier, Goetz" <goetz.lindenmaier at sap.com> wrote:
> 
>> Hi Chris, 
>> 
>> yes, there is no C1 on ppc.  
>> We do tiered compilation with a stripped C2.
> 
> Right.  But some other architecture (or in the future) might need this for C1 as well.  We should find a better place for the value than the ad file.  The obvious place would be compiledIC_<arch>.hpp but we don't have that file, yet.
> 
> I filed:
> 
> 8003853: specify offset of IC load in java_to_interp stub
> 
> -- Chris
> 
>> 
>> Best regards,
>> Goetz
>> 
>> -----Original Message-----
>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
>> Sent: Dienstag, 20. November 2012 22:19
>> To: Lindenmaier, Goetz
>> Cc: hotspot-compiler-dev at openjdk.java.net
>> Subject: Re: RFR (S): Specify offset of IC load in java_to_interp stub.
>> 
>> 
>> On Nov 20, 2012, at 3:08 AM, "Lindenmaier, Goetz" <goetz.lindenmaier at sap.com> wrote:
>> 
>>> Hi,
>>> 
>>> The class CompiledStaticCall must know the location of the IC load in the java_to_interp stub
>>> to update the IC  with NativeMovConstReg.  The current implementation assumes that
>>> the load is always the first instruction in the stub.  This is an artificial restriction. E.g.,
>>> it might be useful to load the constant pool address (MachConstantBase) before the
>>> IC load (as we do on PPC).
>>> 
>>> This change adds a constant specifying an offset from the beginning of the stub to
>>> the  IC load. The offset is platform specific and 0 on sparc and x86.
>>> 
>>> You can find the change here:
>>> http://cr.openjdk.java.net/~goetz/webrevs/webrev-IC_offset/
>> 
>> That should be fixed indeed.  
>> 
>> +#ifndef COMPILER2
>> +const int CompiledStaticCall::comp_to_int_load_offset = 0;
>> 
>> There is no C1 for PPC (sorry, I didn't check)?
>> 
>> -- Chris
>> 
>>> 
>>> or in our ppc port:
>>> http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/c6f9c897ea33
>>> 
>>> Thank you and best regards,
>>> Goetz
>>> 
>>> 
>>> 
>> 
> 



More information about the hotspot-compiler-dev mailing list