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