Request for review(XS): 7013812: C1: deopt blob too far from patching stub
igor.veresov at oracle.com
Thu Jan 20 22:28:08 PST 2011
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
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
>> 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/
>>> 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/
More information about the hotspot-compiler-dev