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

[Igor Veresov]

On 1/20/11 11:30 PM, Tom Rodriguez wrote:
>
> On Jan 20, 2011, at 11:28 PM, Igor Veresov wrote:
>
>> I agree, I also made sure C1 has only one buffer during initialization.
>
> The other jump_to's in there have left them out too so I think that's fine.  Changing the initialization is probably fine too, but why do both?  It seems like it creates more risk.
>

Yeah, you've probably right, I'll leave just the jumps. I was just 
thinking to reduce the risk in case we do something similar in other places.

igor

> tom
>
>>
>> Updated webrev:
>>
>> http://cr.openjdk.java.net/~iveresov/7013812/webrev.01
>>
>> igor
>>
>> On 1/20/11 10:39 PM, Tom Rodriguez wrote:
>>>
>>> On Jan 20, 2011, at 10:28 PM, Igor Veresov wrote:
>>>
>>>> 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.
>>>
>>> That makes sense.  I'd rather just make the code work reliably.  Use the jump.  It's not a performance critical path anyway so a few extra instructions for constant formation don't matter at all.
>>>
>>> tom
>>>
>>>>
>>>> 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
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>