RFR (L): 8134994: use separate VMStructs databases for SA and JVMCI

[Kim Barrett]

On Dec 14, 2015, at 2:46 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
> 
>> ------------------------------------------------------------------------------
>> src/share/vm/gc/shared/cardTableModRefBS.hpp
>>  43 class CardTableModRefBS: public ModRefBarrierSet {
>>  44   // Some classes get to look at some private stuff.
>>  45   friend class VMStructs;
>>  46   friend class JVMCIVMStructs;
>> 
>> I thought we'd eliminated the need for this friendship for JVMCI too,
>> though I'm less certain in this case.  Maybe its just been discussed
>> how it could be done, but hasn't been done yet?
> 
> The friendship exists because of dirty_card which is protected but I can fix that with declare_constant_with_value.  I got rid of the friendship in G1SATBCardTableModRefBS also.

Thanks.  That looks good.

>> ------------------------------------------------------------------------------ 
>> src/share/vm/jvmci/jvmciCompilerToVM.cpp
>> 186     jbyte* base = ((CardTableModRefBS*)bs)->byte_map_base;
>> 
>> Use barrier_set_cast<CardTableModRefBS>(bs), so that when we refactor
>> the barrier set hierarchy (which we plan to do), this will break in an
>> obvious way.
> 
> Done.
> 
>> 
>> And instead of the switch on bs->kind(), maybe use
>> 
>>  if (bs->is_a(BarrierSet::CardTableModRefBS)) {
>>    ... ;
>>  } else {
>>    ShouldNotReachHere();
>>  }
>> 
>> All current implementations of BarrierSet are CTMRBS.  If/when that's
>> no longer true, this will break in an obvious way.
> 
> What about:
> 
>   case BarrierSet::ModRef:
> 
> ?

That case never arises with the known set of barriers.  Let’s not pretend we know what code
should go there.  Better to break in an obvious way if the situation changes, when we’ll know
what needs to be done, rather than unintentionally covering a case incorrectly.

But on further consideration, I’m inclined to leave this as is in webrev.02, for consistency with
all of the other similar switch statements in other code processors.  They can be cleaned up
together as a separate RFE.

> 
> http://cr.openjdk.java.net/~twisti/8134994/webrev.02/

Looks good.