RFR: Move Shenandoah stubs generation into ShenandoahBarrierSetAssembler

Roman Kennke rkennke at redhat.com
Thu Jun 14 13:43:42 UTC 2018


Am 14.06.2018 um 10:26 schrieb Aleksey Shipilev:
> On 06/13/2018 09:57 PM, Roman Kennke wrote:
>> This moves another bunch of Shenandoah code out of shared into
>> Shenandoah specific places. It removes a very significant amount of
>> upstream mess :-) BTW, ShenandoahBarrierSetAssembler is approaching 1000
>> LOC :-)
>>
>> It builds on top of my previous patch to move runtime entries into
>> ShenandoahRuntime. This needs to go in first.
>>
>> Testing: tier3_gc_shenandoah (ongoing, expected clean before push)
>>
>> http://cr.openjdk.java.net/~rkennke/shstubgen/webrev.00/
> 
> Good change!
> 
> *) I think you can put the assert right inside the SBSA::shenandoah_wb() call in both
> macroAssembler_aarch64.cpp and macroAssembler_x86.cpp:
> 
> 4099   assert(ShenandoahBarrierSetAssembler::shenandoah_wb() != NULL, "need write barrier stub");
> 4100   far_call(RuntimeAddress(CAST_FROM_FN_PTR(address,
> ShenandoahBarrierSetAssembler::shenandoah_wb())));
> 
> 
> *) This revert, you sure aarch64 still runs fine after it? We can take in on faith, and see what
> testing shows, but at least we should have basic idea about its safety:
> 
>   44   code_size2 = 22000           // simply increase if too small (assembler will crash if too small)
> 
> 
> *) In lcm.cpp, you need to #include "utilities/macros.hpp" to gain access to INCLUDE_SHENANDOAHGC macro
> 
> *) In lcm.cpp, please use braces for "else":
> 
>  899 #if INCLUDE_SHENANDOAHGC
>  900   if (UseShenandoahGC && mcall->entry_point() ==
> ShenandoahBarrierSetAssembler::shenandoah_wb_C()) {
>  901     assert(op == Op_CallLeafNoFP, "shenandoah_wb_C should be called with Op_CallLeafNoFP");
>  902     add_call_kills(proj, regs, save_policy, exclude_soe, true);
>  903   } else
>  904 #endif
>        {  <--- here
>  905     add_call_kills(proj, regs, save_policy, exclude_soe, false);
>        }  <--- and here
>  906
>  907   return node_cnt;
> 
> 

ok, all of this, plus missing includes for PCH:

Incremental:
http://cr.openjdk.java.net/~rkennke/shstubgen/webrev.01.diff/
Full:
http://cr.openjdk.java.net/~rkennke/shstubgen/webrev.01/

Roman



More information about the shenandoah-dev mailing list