Request for review(XS): 7013812: C1: deopt blob too far from patching stub

[Igor Veresov]

On 1/20/11 10:15 PM, Igor Veresov wrote:
> On 1/20/11 10:09 PM, Tom Rodriguez wrote:
>> Actually, how does this happen? deopt blob and patching stubs are
>> created pretty early so how could they be that far apart? The branch
>> has a signed reach of 22 bits worth of words so it can reach +/- 8M.
>> How could there be 8M between the deopt blob and the patching stub?
>>
>
> For sparcv9 we generate "bp", which have a range of 2^19 of words, see
> MacroAssembler::br().

Actually I just understood the root cause: this all happened because we 
create a bunch of C1 threads, each of which allocate a code buffer for 
themselves and only after that the stub started to be generated. So, 
another fix could be to allocate buffers for each thread after 
initialization and allow only the initializing thread to allocate one 
buffer first.

igor

>
> igor
>
>> tom
>>
>> On Jan 20, 2011, at 9:45 PM, Igor Veresov wrote:
>>
>>> After a bit of a thought, I decided to leave the 32bit as it was.
>>> Webrev updated: http://cr.openjdk.java.net/~iveresov/7013812/webrev.00/
>>>
>>> igor
>>>
>>> On 1/20/11 9:28 PM, Igor Veresov wrote:
>>>> access_filed_patching and load_klass_patching stubs are using
>>>> effectively a bp instruction to jump to deopt blob. This limits the
>>>> distance between the deopt blob and these stub to 2^20, which is not
>>>> enough. Since this situation could become possible also with a 32bit VM
>>>> (the distance is only 1M), I decided to always use long jumps.
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~iveresov/7013812/webrev.00/
>>>>
>>>> Thanks,
>>>> igor
>>>>
>>>
>>>
>>
>