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

[Tom Rodriguez]

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_live_registers(sasm);
-  __ restore();
+#ifdef _LP64
+  __ relocate(relocInfo::runtime_call_type);
+  AddressLiteral dest(deopt_blob->unpack_with_reexecution());
+  __ jump_to(dest, O0);
+#else
   __ br(Assembler::always, false, Assembler::pt, deopt_blob->unpack_with_reexecution(), relocInfo::runtime_call_type);
-  __ delayed()->nop();
+#endif
+  __ delayed()->restore();
 
   __ bind(no_deopt);
   restore_live_registers(sasm);

This is similar to what is done in generate_handle_exception for similar reasons.

tom

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