[aarch64-port-dev ] RFR: Add support for G1GC

[Edward Nevill]

On Tue, 2014-03-18 at 11:12 +0000, Andrew Haley wrote:
> On 03/18/2014 10:52 AM, Edward Nevill wrote:
> > +// Store CMS card-mark Immediate
> > +instruct storeimmCM0(immI0 zero, memory mem)
> > +%{
> > +  match(Set mem (StoreCM mem zero));
> > +
> > +  ins_cost(MEMORY_REF_COST);
> > +  format %{ "strb zr, $mem\t# byte" %}
> > +
> > +  ins_encode(aarch64_enc_strb0(mem));
> 
> Are you sure this isn't a store release?  I'm not sure.

I don't believe a store release is necessary.

It does a full mem barrier in g1_write_barrier_post.

See jdk8/hotspot/src/share/vm/opto/graphKit.cpp

   4014           // Use Op_MemBarVolatile to achieve the effect of a StoreLoad barrier.
   4015           insert_mem_bar(Op_MemBarVolatile, oop_store);
   4016           __ sync_kit(this);
   4017 
   4018           Node* card_val_reload = __ load(__ ctrl(), card_adr, TypeInt::INT, T_BYTE, Compile::AliasIdxRaw);
   4019           __ if_then(card_val_reload, BoolTest::ne, dirty_card); {
   4020             g1_mark_card(ideal, card_adr, oop_store, alias_idx, index, index_adr, buffer, tf);

This is also in line with what is done for C1 and for the template interpreter.

> 
> > @@ -1866,47 +1866,47 @@
> >  void LIR_Assembler::logic_op(LIR_Code code, LIR_Opr left, LIR_Opr right, LIR_Opr dst) {

> What is this rewrite of logic_op for?  Is it part of this patch?

OK. So I found that LIR was being passed to logic_op with a mixture of single and double CPU registers.

This was from LIRGenerator::G1SATBCardTableModRef_post_barrier in src/share/vm/c1/c1_LIRGenerator.cpp.

I started hacking G1SATBCardTableModRef_post_barrier but there were more cases and the hack started to grow.

Rather than put a growing AARCH64 specific hack in shared code I decided that the most expedient think to do would be to make logic_op accept the mix. This is what happens on x86 in any case.

I predicated this on the size of dst. IE if dst is 32 bit then the whole expression must be 32 bit, otherwise if the dst is 64 bit the operands are treated as 64 bit.

> 
> > +	//__ push(r0->bit(1) | r1->bit(1), sp);
> > +	__ push(r0->bit(1) | r1->bit(1) | rscratch1->bit(1) | rscratch2->bit(1), sp);
> 
> What is the commented-out code for?  Why is this particular set of registers
> pushed?

It should be push(r0, r1), the push of rscratch1, rscratch2 is unnecessary.

r0 needs to be saved, I also push r1 because it is free and because I need to save r0..r7 around the call to g1_wb_post later and by saving r1 here I only have to save r2..r7 later.

> 
> > +  // Calling the runtime using the regular call_VM_leaf mechanism generates
> > +  // code (generated by InterpreterMacroAssember::call_VM_leaf_base)
> > +  // that checks that the *(ebp+frame::interpreter_frame_last_sp) == NULL.

It seems to check rfp + frame::interpreter_frame_last_sp.

Thanks for the review!

Ed.