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

[Dean Long]

Thanks Vlad and Mikael for the reviews.

dl

On 6/21/2012 3:13 PM, Vladimir Danushevsky wrote:
> Looks fine (in case you need one more reviewer)
>
> On Jun 21, 2012, at 2:28 PM, Dean Long wrote:
>
>> I filed 7178842 for future cleanup.  Mikael, can I count you as a 
>> reviewer for the current webrev?
>>
>> I also need a review from a Reviewer.
>>
>> dl
>>
>> On 6/19/2012 4:54 PM, Mikael Vidstedt wrote:
>>>
>>> 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
>>>>>
>>>
>