RFR: Move Shenandoah stubs generation into ShenandoahBarrierSetAssembler

[Roman Kennke]

Am 14.06.2018 um 15:43 schrieb Roman Kennke:
> 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/
> 

Except that some monster ate my webrev.


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