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

[Vladimir Danushevsky]

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
>>>>
>>