RFR(M): 8167184: [s390] Extend relocations for pc-relative instructions.

[Lindenmaier, Goetz]

Hi,

this change had conflicts with 8166377.  I rebased the change, 
resolved the conflicts and replaced the webrev. No changes to our code:
http://cr.openjdk.java.net/~goetz/wr16/8167184-s390_relocations/webrev.02/

Best regards,
  Goetz.

> -----Original Message-----
> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
> Sent: Montag, 10. Oktober 2016 18:21
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-compiler-
> dev at openjdk.java.net
> Subject: Re: RFR(M): 8167184: [s390] Extend relocations for pc-relative
> instructions.
> 
> Good.
> 
> Thanks,
> Vladimir
> 
> On 10/10/16 2:36 AM, Lindenmaier, Goetz wrote:
> > Hi Vladimir,
> >
> > I added S390_ONLY macros around the field declaration and the two
> > methods so that set_ctable_begin should be inlined as empty method
> > and optimized away on non-s390 platforms.
> > http://cr.openjdk.java.net/~goetz/wr16/8167184-
> s390_relocations/webrev.02/
> >
> > Best regards,
> >   Goetz.
> >
> >
> >> -----Original Message-----
> >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
> >> Sent: Donnerstag, 6. Oktober 2016 18:34
> >> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-
> compiler-
> >> dev at openjdk.java.net
> >> Subject: Re: RFR(M): 8167184: [s390] Extend relocations for pc-relative
> >> instructions.
> >>
> >> On 10/6/16 8:48 AM, Lindenmaier, Goetz wrote:
> >>> Hi Vladimir,
> >>>
> >>> your're right, adding a field to CodeBlob will blow up nmethods on all
> >>> platforms, so I agree having an #ifdef makes sense.
> >>> But for the relocation, it's just an extra class, should not
> >>> matter too much, but it's much clearer than adding #ifdefs I think.
> >>
> >> Okay, I am fine with new relocation class since it is not used on other
> >> platforms.
> >>
> >> Thanks,
> >> Vladimir
> >>
> >>>
> >>> I edited the bug to mention 'constant section".
> >>>
> >>> Best regards,
> >>>   Goetz.
> >>>
> >>>> -----Original Message-----
> >>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
> >>>> Sent: Mittwoch, 5. Oktober 2016 20:27
> >>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-
> >> compiler-
> >>>> dev at openjdk.java.net
> >>>> Subject: Re: RFR(M): 8167184: [s390] Extend relocations for pc-relative
> >>>> instructions.
> >>>>
> >>>> When you say "constant pool" do you mean "conatant section" in code
> >>>> buffer? Or CP in class data? I assume first. It is confusing.
> >>>>
> >>>> Can you implement this as S390 code (#ifdef)? I am not comfortable
> that
> >>>> code is executed on other platforms too (ctable setting).
> >>>>
> >>>> Can you add _offset under #ifdef to runtime_call_Relocation instead? I
> >>>> see that s390 code use it this way:
> >>>>
> >>>> +    if (type() == relocInfo::runtime_call_type) {
> >>>> +      toc_offset = ((runtime_call_Relocation
> >>>> *)this)->get_constant_pool_offset();
> >>>>
> >>>> Thanks,
> >>>> Vladimir
> >>>>
> >>>> On 10/5/16 8:16 AM, Lindenmaier, Goetz wrote:
> >>>>> Hi,
> >>>>>
> >>>>>
> >>>>>
> >>>>> This extension to relocations is needed for the s390 port.
> >>>>>
> >>>>> Please review:
> >>>>>
> >>>>> http://cr.openjdk.java.net/~goetz/wr16/8167184-
> >>>> s390_relocations/webrev.01/
> >>>>>
> >>>>>
> >>>>> This change implements two extensions to relocation to support
> >>>>> pc-relative instructions.
> >>>>>
> >>>>> On s390, there are call instructions that branch to an address relative
> >>>>> to the current pc. If the offset encodable in the instruction does not
> >>>>> suffice,  our port uses a pc-relative load to load the target address
> >>>>> from the constant pool into a register that is then used as branch
> >>>>> target. Relocations must support switching between these two
> >>>>> implementations. For this we need a relocation that stores the offset
> of
> >>>>> the address in the constant pool, as this value can not be read from
> the
> >>>>> instruction.
> >>>>>
> >>>>> Further the pc-relative instructions encode the offset from the
> >>>>> instruction to the constant. If the constant pool is resized, or the
> >>>>> instruction is moved (as during shorten branches), this offset must be
> >>>>> adapted. To compute the new offset, the change in offset must be
> >> known.
> >>>>> To compute this we store the position of the constant pool in the
> >>>> CodeBlob.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Best regards,
> >>>>>
> >>>>>   Goetz.
> >>>>>