Request for review(XS): 7013812: C1: deopt blob too far from patching stub
igor.veresov at oracle.com
Thu Jan 20 22:19:14 PST 2011
On 1/20/11 10:00 PM, Tom Rodriguez wrote:
> 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/
> Can't G3 have live values in it? I think you might have to do:
> diff -r 5ae3e3b03224 src/cpu/sparc/vm/c1_Runtime1_sparc.cpp
> --- a/src/cpu/sparc/vm/c1_Runtime1_sparc.cpp Thu Jan 13 07:28:47 2011 -0800
> +++ b/src/cpu/sparc/vm/c1_Runtime1_sparc.cpp Thu Jan 20 21:57:50 2011 -0800
> @@ -343,9 +343,14 @@
> // returned.
> - __ restore();
> +#ifdef _LP64
> + __ relocate(relocInfo::runtime_call_type);
> + AddressLiteral dest(deopt_blob->unpack_with_reexecution());
> + __ jump_to(dest, O0);
> __ br(Assembler::always, false, Assembler::pt, deopt_blob->unpack_with_reexecution(), relocInfo::runtime_call_type);
> - __ delayed()->nop();
> + __ delayed()->restore();
> __ bind(no_deopt);
> This is similar to what is done in generate_handle_exception for similar reasons.
Thanks, Tom, webrev updated.
One, question. Will we ever have to do the relocation for this jump
sequence? It will be currently matched as a far call by the relocation
logic, for which we don't do anything.
Another fix though, can be just to always generate true br, which should
give enough range.
>> 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