review request for 7156729: PPC: R_PPC_REL24 relocation error related to some libraries built without -fPIC

[Mikael Vidstedt]

Sounds like a great idea!

Cheers,
Mikael

On 2012-06-19 16:43, Dean Long wrote:
> How about I file a separate RFE for that?  I would like to minimize 
> changes for an update release, and I'm worried I might accidentally 
> break something that we aren't  building, like "zero".
>
> dl
>
> On 6/19/2012 3:29 PM, Mikael Vidstedt wrote:
>>
>> Dean,
>>
>> Can I suggest that you turn the logic around to instead list/test for 
>> the platforms where we know we can use the nonpic optimization? That 
>> way we'll avoid running into this type of problem again.
>>
>> Cheers,
>> Mikael
>>
>> On 2012-06-18 00:07, Dean Long wrote:
>>> http://cr.openjdk.java.net/~dlong/7156729/
>>> Summary of changes:    8 lines changed: 7 ins; 0 del; 1 mod; 40 unchg
>>>
>>> Non-PIC objects have a limited range when calling external 
>>> functions, so dynamic linking can fail if for example libc is too 
>>> far away.  The solution is to build all powerpc objects with -fPIC, 
>>> including the oops and gc directories that were previously 
>>> excluded.  This causes calls to go through the PLT.  PIC_ARCH is a 
>>> list that can be expanded later (ARM could be next).  I also tried 
>>> using -mlongcall instead of -fPIC, but it doesn't have any 
>>> performance advantage over -fPIC and it causes a 17% increase in 
>>> static footprint vs. a 5% decrease for -fPIC.
>>>
>>> To measure the performance regression, I ran some refworkload 
>>> benchmarks with different heap sizes.  As expected, the smaller the 
>>> heap, the bigger the slowdown.  With a 32m heap, specjvm98 "javac" 
>>> slows down by 2.5%.  The GC logs show about a 6% slowdown in pause 
>>> times.
>>>
>>> There are some known issues with -fPIC overhead in the current 
>>> toolchain, so we expect to gain much of the performance back in the 
>>> future when we can move to a newer toolchain.  But since this is 
>>> targeted for 7u6/hs23.2, there isn't much choice for now.
>>>
>>> dl
>>